<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 30, 2018 at 3:18 AM, Christian Mauderer <span dir="ltr"><<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Am 29.04.2018 um 23:08 schrieb Joel Sherrill:<br>
> <br>
> <br>
> On Sun, Apr 29, 2018, 3:32 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de">list@c-mauderer.de</a><br>
</span><span class="gmail-">> <mailto:<a href="mailto:list@c-mauderer.de">list@c-mauderer.de</a>>> wrote:<br>
> <br>
>     Am 28.04.2018 um 21:45 schrieb Gedare Bloom:<br>
>     > On Thu, Apr 26, 2018 at 7:52 PM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a><br>
</span><span class="gmail-">>     <mailto:<a href="mailto:joel@rtems.org">joel@rtems.org</a>>> wrote:<br>
>     >> Hi<br>
>     >><br>
>     >> Teaching the class this week, i have noticed that randomly some<br>
>     >> files are executable. I was going to change this but then realized<br>
>     >> that we should all agree on what the permissions on the files and<br>
>     >> directories in the tree(s) should be.<br>
>     >><br>
>     >> I lean to either:<br>
>     >><br>
>     >> + 664 for files and 775 for directories<br>
>     >><br>
>     >> But could be talked into tighter permissions for group and world.<br>
>     >> Whatever we do, it should be consistent and added to the Coding<br>
>     >> Conventions.<br>
>     >><br>
>     ><br>
>     > Your proposal is sensible to me.<br>
> <br>
>     Hello Joel,<br>
> <br>
>     I wouldn't really have a problem with these. But I think the more usual<br>
>     ones would be 644 and 755.<br>
> <br>
>     If I create a new file using `touch somefile` in a directory with 775, I<br>
>     still get a 644 file (at least on my Linux machine - I'm not sure<br>
>     whether it is configuration dependant). I think that we will get a lot<br>
>     of patches with "wrong" permissions if we use 664 and 775. So maybe it<br>
>     would be good to have some reasons for using these wider group<br>
>     permissions.<br>
> <br>
> <br>
> The command you are thinking of is umask to set your default file<br>
> permissions. <br>
> <br>
<br>
</span>I knew I have seen a setting sometimes. You are right: I have though of<br>
umask. I only don't need it often enough to remember ;-)<br>
<span class="gmail-"><br>
> <br>
>     The only setup that I could think of where such rights might could be<br>
>     useful is one where one user updates the code while some other user (for<br>
>     example a build bot) has to run a bootstrap to build the tree. But I'm<br>
>     quite sure that even for that case, there are some better solutions<br>
>     (e.g. one working tree that only pushes to a build bot tree).<br>
> <br>
> <br>
> If all commits go through a git or patch tester server, i would assume<br>
> that we are getting the permissions set by the patch submitter.<br>
> <br>
> I suspect (no investigation) that we could have a git check that ensures<br>
> specific permissions based on the file extension.<br>
> <br>
<br>
</span>That would be great.<br></blockquote><div><br></div><div>Should we file that as an admin "wish list" item? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> <br>
>     Any special reasons, use cases or experiences where the 664 and 775<br>
>     would be superior to 644 and 755?<br>
> <br>
> <br>
> No. I just remember historically using those on real multi-user devel<br>
> machines so everyone on a team could share source.<br>
> <br>
> I think we all agree it should be standardized. That's a good step.<br>
> <br>
> I will look at git, GNU recommendations and a few packages to see what<br>
> they do. Then make a proposal which might include ways to try to keep<br>
> this standardized.<br>
> <br>
<br>
</span>Maybe it's already decided by git:<br>
<br>
I did a quick test: I initialized an empty repository (called test) and<br>
created the following files there:<br>
<br>
-rw-r--r-- 1 christian users 0 30. Apr 10:05 644<br>
-rw-rw-r-- 1 christian users 0 30. Apr 10:05 664<br>
-rw-rw-rw- 1 christian users 0 30. Apr 10:05 666<br>
-rwxr-xr-x 1 christian users 0 30. Apr 10:04 755<br>
-rwxrwxr-x 1 christian users 0 30. Apr 10:05 775<br>
-rwxrwxrwx 1 christian users 0 30. Apr 10:05 777<br>
<br>
Then I did a `git add .` and commited it. If I clone that repository<br>
with `git clone test test2` my test2 folder contains the following files:<br>
<br>
-rw-r--r-- 1 christian users 0 30. Apr 10:07 644<br>
-rw-r--r-- 1 christian users 0 30. Apr 10:07 664<br>
-rw-r--r-- 1 christian users 0 30. Apr 10:07 666<br>
-rwxr-xr-x 1 christian users 0 30. Apr 10:07 755<br>
-rwxr-xr-x 1 christian users 0 30. Apr 10:07 775<br>
-rwxr-xr-x 1 christian users 0 30. Apr 10:07 777<br>
<br>
If I re-set the permissions, that is not shown as a change. Only the<br>
executable bit seems to be saved. All other permissions are not saved in<br>
my test setup.<br></blockquote><div><br></div><div>The reading I have done indicates that only the executable bit is</div><div>managed by git. The rest are from your umask (I thin).</div><div><br></div><div><div>find . -type f -executable | grep -v .git | grep -v configure</div></div><div><br></div><div>Turns up a number of source files which are executable. given that git</div><div>tracks that, I fixed those. That leaves these as executable. The worst</div><div>I see on this list is some that are likely obsolete. Do you see anything</div><div>else?</div><div><br></div><div><div>/compile</div><div>./cpukit/doxy-filter</div><div>./cpukit/sapi/vc-key.sh</div><div>./depcomp</div><div>./install-sh</div><div>./mdate-sh</div><div>./missing</div><div>./testsuites/fstests/fsdosfsname01/create_image.sh</div><div>./testsuites/smptests/smplock01/smplock01fair.py</div><div>./testsuites/smptests/smplock01/smplock01perf.py</div><div>./testsuites/sptests/sptimecounter02/sptimecounter02.py</div><div>./tools/build/cvsignore-add.sh</div><div>./tools/build/doxy-filter</div><div>./tools/build/multigen</div><div>./tools/build/rtems-test-check</div><div>./tools/build/rtems-test-check-py</div><div>./tools/build/rtems-testsuite-autostuff</div><div>./ampolish3</div><div>./bootstrap</div><div>./bsps/nios2/nios2_iss/nios2_iss.sh</div><div>./config.guess</div><div>./config.sub</div><div>./rtems-bsps</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best regards<br>
<br>
Christian<br>
<span class="gmail-"><br>
> <br>
>     Best regards<br>
> <br>
>     Christian Mauderer<br>
> <br>
>     ><br>
>     >> Thoughts<br>
>     >><br>
>     >> ______________________________<wbr>_________________<br>
>     >> devel mailing list<br>
</span>>     >> <a href="mailto:devel@rtems.org">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org">devel@rtems.org</a>><br>
<span class="gmail-">>     >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
>     > ______________________________<wbr>_________________<br>
>     > devel mailing list<br>
</span>>     > <a href="mailto:devel@rtems.org">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org">devel@rtems.org</a>><br>
>     > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
>     ><br>
> <br>
<br>
</blockquote></div><br></div></div>