On Mon, Apr 30, 2018 at 3:18 AM, Christian Mauderer <l...@c-mauderer.de> wrote:
> Am 29.04.2018 um 23:08 schrieb Joel Sherrill: > > > > > > On Sun, Apr 29, 2018, 3:32 PM Christian Mauderer <l...@c-mauderer.de > > <mailto:l...@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 <j...@rtems.org > > <mailto:j...@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@rtems.org <mailto:devel@rtems.org> > > >> http://lists.rtems.org/mailman/listinfo/devel > > > _______________________________________________ > > > devel mailing list > > > devel@rtems.org <mailto:devel@rtems.org> > > > http://lists.rtems.org/mailman/listinfo/devel > > > > > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
