Re: [lmi] Sharing git repositories

[Greg Chicares]

On 2020-03-04 00:39, Vadim Zeitlin wrote:
> On Wed, 4 Mar 2020 00:17:06 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> It seemed like a good idea to do 'chmod -R 664 *',
> 
>  I shuddered a bit while reading this because this reminded me about my own
> bad experiences with similar commands. I'm not 100% sure, but I strongly
> believe that using chmod with a fixed mode is never a good idea. Using it
> with "g+w" or "g+rx" or even "o-rx" may be useful, but not setting the mode
> unconditionally.

Then these occurrences should be reconsidered:

/opt/lmi/src/lmi[0]$ grep -r '[Cc][Hh][Mm][Oo][Dd].*[0-9][0-9][0-9]' *
gwc/develop0.txt:chmod 600 ~/.ssh/*
install_centos.sh:chmod 666 /dev/null
install_centos.sh:chmod 666 /dev/ptmx
install_miscellanea.make:       $(CHMOD) 750 $(cache_dir)/$@
lmi_setup_20.sh:chmod 755 /usr/sbin/policy-rc.d

Do you object to any use of chmod with octal constants, or only to
such constants with directory traversal (e.g., '-R' or 'find ...')?
I should think that 'chmod 600 ~/.ssh/*' is unimpugnable, and that
0666 is okay for the /dev/whatever stuff in 'install_centos.sh'.

As for some-chroot/usr/sbin/policy-rc.d, we discussed that here:
  https://lists.nongnu.org/archive/html/lmi/2020-02/msg00015.html
and I think we concluded that 'chmod 755' was good there, although
upon careful re-reading it looks like you preferred '775', with
'7' in the middle so that system pseudo-users can run it, right?

Last and worst of all is the
  $(CHMOD) 750 $(cache_dir)/$@
line, committed a dozen years ago:
  git show 9fdaec5d0e7c
whose intention is to ensure that 'md5sum' is executable. This
is one of a few commands that have failed in the last few days
when either Kim or I tried to build everything from scratch using
cached files belonging to the other user. Here, "750" per se is
not the problem--it's that 'chmod' can be run only by the owner
(or by root), and I can't chmod one of her files even if she
gives it 0777 permissions. This raises two questions:

 - Would something like "u+x,g+x" be better than "750" here, e.g.
for a file that has been freshly obtained via wget? I suppose the
idea is that wget gives files something like 06?? permissions,
depending on whatever umask happens to be; then
  - "u+x,g+x" would turn on the user and group 'x' bits, leaving
    all other bits alone, whereas
  - "750" would prescribe everything,
so the two arguments have different meanings, neither of which
is necessarily right or wrong. But maybe that doesn't matter,
because...

 - Why on earth did this ever seem necessary? It doesn't matter
on msw, which has no 'x' bit. It doesn't matter on GNU/Linux:
  /opt/lmi/bin[0]$cp md5sum.exe eraseme.exe
  /opt/lmi/bin[0]$chmod -x eraseme.exe
  /opt/lmi/bin[0]$ls -l e*.exe
  -rwxr-xr-x 1 greg greg 1867808 Jan 18 00:54 elapsed_time.exe
  -rw-r----- 1 greg greg   49152 Mar  4 20:19 eraseme.exe
  /opt/lmi/bin[0]$wine eraseme.exe --version           
  md5sum (PCP patchlevel 2) (GNU textutils) 1.22
It doesn't matter on cygwin, where according to
  https://cygwin.com/cygwin-ug-net/using-filemodes.html
executability depends on the file extension, a hashbang, or
ACLs, but the 'x' bit is always disregarded. And it doesn't
matter even when we prepare an msw distribution on GNU/Linux
or cygwin and then copy the files onto native msw. Can this
  $(CHMOD) 750 $(cache_dir)/$@
line ever have had any discernible effect (other than
creating an obstacle to portability to a multi-user machine)?
I'm thinking I should just remove it.