Source File Permissions
Christian Mauderer
list at c-mauderer.de
Tue May 1 08:40:13 UTC 2018
Am 01.05.2018 um 00:23 schrieb Joel Sherrill:
>
>
> On Mon, Apr 30, 2018 at 3:18 AM, Christian Mauderer <list at c-mauderer.de
> <mailto: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>
> > <mailto: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>
> > <mailto: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?
>
I think in the long run, that would be something like the linux
checkpatch.pl script that checks whether the coding style matches the
ones that we accept:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl?h=v4.17-rc3
But I don't think that anyone has the time to do it. So really a long
term project. Beneath that even if we already have a coding style
recommendation such a script would for sure start the discussion about
THE RIGHT CODING STYLE which is quite a matter of faith and therefore a
really annoying discussion (and please let's not start it here and now).
>
> >
> > 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).
Great. So it's no difference whether we use 664 or 644.
>
> 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
>
The find on my computer found a
./bsps/arm/shared/start/start.S
which shouldn't be executable too. Otherwise I would be OK with that.
Best regards
Christian
>
>
>
> Best regards
>
> Christian
>
> >
> > Best regards
> >
> > Christian Mauderer
> >
> > >
> > >> Thoughts
> > >>
> > >> _______________________________________________
> > >> devel mailing list
> > >> devel at rtems.org <mailto:devel at rtems.org>
> <mailto:devel at rtems.org <mailto:devel at rtems.org>>
> > >> http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>
> > > _______________________________________________
> > > devel mailing list
> > > devel at rtems.org <mailto:devel at rtems.org>
> <mailto:devel at rtems.org <mailto:devel at rtems.org>>
> > > http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>
> > >
> >
>
>
More information about the devel
mailing list