Source File Permissions

Joel Sherrill joel at rtems.org
Mon Apr 30 22:23:06 UTC 2018 

On Mon, Apr 30, 2018 at 3:18 AM, Christian Mauderer <list at c-mauderer.de>
wrote:

> 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.
>

Should we file that as an admin "wish list" item?

>
> >
> >     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.
>

The reading I have done indicates that only the executable bit is
managed by git. The rest are from your umask (I thin).

find . -type f -executable | grep -v .git | grep -v configure

Turns up a number of source files which are executable. given that git
tracks that, I fixed those. That leaves these as executable. The worst
I see on this list is some that are likely obsolete. Do you see anything
else?

/compile
./cpukit/doxy-filter
./cpukit/sapi/vc-key.sh
./depcomp
./install-sh
./mdate-sh
./missing
./testsuites/fstests/fsdosfsname01/create_image.sh
./testsuites/smptests/smplock01/smplock01fair.py
./testsuites/smptests/smplock01/smplock01perf.py
./testsuites/sptests/sptimecounter02/sptimecounter02.py
./tools/build/cvsignore-add.sh
./tools/build/doxy-filter
./tools/build/multigen
./tools/build/rtems-test-check
./tools/build/rtems-test-check-py
./tools/build/rtems-testsuite-autostuff
./ampolish3
./bootstrap
./bsps/nios2/nios2_iss/nios2_iss.sh
./config.guess
./config.sub
./rtems-bsps



>
> 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
> >     >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180430/76227eb6/attachment-0002.html>

More information about the devel mailing list