Source File Permissions

[Christian Mauderer]

Am 29.04.2018 um 23:08 schrieb Joel Sherrill:
> 
> 
> On Sun, Apr 29, 2018, 3:32 PM Christian Mauderer <list at c-mauderer.de
> <mailto:list at c-mauderer.de>> wrote:
> 
>     Am 28.04.2018 um 21:45 schrieb Gedare Bloom:
>     > On Thu, Apr 26, 2018 at 7:52 PM, Joel Sherrill <joel at rtems.org
>     <mailto:joel at rtems.org>> wrote:
>     >> Hi
>     >>
>     >> Teaching the class this week, i have noticed that randomly some
>     >> files are executable. I was going to change this but then realized
>     >> that we should all agree on what the permissions on the files and
>     >> directories in the tree(s) should be.
>     >>
>     >> I lean to either:
>     >>
>     >> + 664 for files and 775 for directories
>     >>
>     >> But could be talked into tighter permissions for group and world.
>     >> Whatever we do, it should be consistent and added to the Coding
>     >> Conventions.
>     >>
>     >
>     > Your proposal is sensible to me.
> 
>     Hello Joel,
> 
>     I wouldn't really have a problem with these. But I think the more usual
>     ones would be 644 and 755.
> 
>     If I create a new file using `touch somefile` in a directory with 775, I
>     still get a 644 file (at least on my Linux machine - I'm not sure
>     whether it is configuration dependant). I think that we will get a lot
>     of patches with "wrong" permissions if we use 664 and 775. So maybe it
>     would be good to have some reasons for using these wider group
>     permissions.
> 
> 
> The command you are thinking of is umask to set your default file
> permissions. 
> 

I knew I have seen a setting sometimes. You are right: I have though of
umask. I only don't need it often enough to remember ;-)

> 
>     The only setup that I could think of where such rights might could be
>     useful is one where one user updates the code while some other user (for
>     example a build bot) has to run a bootstrap to build the tree. But I'm
>     quite sure that even for that case, there are some better solutions
>     (e.g. one working tree that only pushes to a build bot tree).
> 
> 
> If all commits go through a git or patch tester server, i would assume
> that we are getting the permissions set by the patch submitter.
> 
> I suspect (no investigation) that we could have a git check that ensures
> specific permissions based on the file extension.
> 

That would be great.

> 
>     Any special reasons, use cases or experiences where the 664 and 775
>     would be superior to 644 and 755?
> 
> 
> No. I just remember historically using those on real multi-user devel
> machines so everyone on a team could share source.
> 
> I think we all agree it should be standardized. That's a good step.
> 
> I will look at git, GNU recommendations and a few packages to see what
> they do. Then make a proposal which might include ways to try to keep
> this standardized.
> 

Maybe it's already decided by git:

I did a quick test: I initialized an empty repository (called test) and
created the following files there:

-rw-r--r-- 1 christian users 0 30. Apr 10:05 644
-rw-rw-r-- 1 christian users 0 30. Apr 10:05 664
-rw-rw-rw- 1 christian users 0 30. Apr 10:05 666
-rwxr-xr-x 1 christian users 0 30. Apr 10:04 755
-rwxrwxr-x 1 christian users 0 30. Apr 10:05 775
-rwxrwxrwx 1 christian users 0 30. Apr 10:05 777

Then I did a `git add .` and commited it. If I clone that repository
with `git clone test test2` my test2 folder contains the following files:

-rw-r--r-- 1 christian users 0 30. Apr 10:07 644
-rw-r--r-- 1 christian users 0 30. Apr 10:07 664
-rw-r--r-- 1 christian users 0 30. Apr 10:07 666
-rwxr-xr-x 1 christian users 0 30. Apr 10:07 755
-rwxr-xr-x 1 christian users 0 30. Apr 10:07 775
-rwxr-xr-x 1 christian users 0 30. Apr 10:07 777

If I re-set the permissions, that is not shown as a change. Only the
executable bit seems to be saved. All other permissions are not saved in
my test setup.

Best regards

Christian

> 
>     Best regards
> 
>     Christian Mauderer
> 
>     >
>     >> Thoughts
>     >>
>     >> _______________________________________________
>     >> devel mailing list
>     >> devel at rtems.org <mailto:devel at rtems.org>
>     >> http://lists.rtems.org/mailman/listinfo/devel
>     > _______________________________________________
>     > devel mailing list
>     > devel at rtems.org <mailto:devel at rtems.org>
>     > http://lists.rtems.org/mailman/listinfo/devel
>     >
>