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