Re: [lmi] Sharing git repositories

[Vadim Zeitlin]

On Wed, 4 Mar 2020 21:01:02 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2020-03-04 00:39, Vadim Zeitlin wrote:
GC> > On Wed, 4 Mar 2020 00:17:06 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> It seemed like a good idea to do 'chmod -R 664 *',
GC> > 
GC> >  I shuddered a bit while reading this because this reminded me about my 
own
GC> > bad experiences with similar commands. I'm not 100% sure, but I strongly
GC> > believe that using chmod with a fixed mode is never a good idea. Using it
GC> > with "g+w" or "g+rx" or even "o-rx" may be useful, but not setting the 
mode
GC> > unconditionally.
GC> 
GC> Then these occurrences should be reconsidered:
GC> 
GC> /opt/lmi/src/lmi[0]$ grep -r '[Cc][Hh][Mm][Oo][Dd].*[0-9][0-9][0-9]' *
GC> gwc/develop0.txt:chmod 600 ~/.ssh/*
GC> install_centos.sh:chmod 666 /dev/null
GC> install_centos.sh:chmod 666 /dev/ptmx
GC> install_miscellanea.make:       $(CHMOD) 750 $(cache_dir)/$@
GC> lmi_setup_20.sh:chmod 755 /usr/sbin/policy-rc.d
GC> 
GC> Do you object to any use of chmod with octal constants, or only to
GC> such constants with directory traversal (e.g., '-R' or 'find ...')?

 Sorry, I definitely meant that using a _recursive_ chmod with a fixed mode
is never a good idea. Of course, this would have been more clear if I
hadn't omitted the key word in this sentence accidentally.

GC> I should think that 'chmod 600 ~/.ssh/*' is unimpugnable, and that
GC> 0666 is okay for the /dev/whatever stuff in 'install_centos.sh'.

 Yes, absolutely.

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

 Did I? If so, I must have been confused because 775 is sufficient for
this anyhow...

GC> Last and worst of all is the
GC>   $(CHMOD) 750 $(cache_dir)/$@
GC> line, committed a dozen years ago:
GC>   git show 9fdaec5d0e7c
GC> whose intention is to ensure that 'md5sum' is executable.

 Would it be horribly impolite to use this as an opportunity to remind you
about https://github.com/vadz/lmi/pull/117, even if it's not directly
related to this problem?

GC> This
GC> is one of a few commands that have failed in the last few days
GC> when either Kim or I tried to build everything from scratch using
GC> cached files belonging to the other user. Here, "750" per se is
GC> not the problem--it's that 'chmod' can be run only by the owner
GC> (or by root), and I can't chmod one of her files even if she
GC> gives it 0777 permissions. This raises two questions:
GC> 
GC>  - Would something like "u+x,g+x" be better than "750" here,

 I guess it could be if you wanted to be really careful, but I don't see
any reason why would it matter in practice. And it would still result in an
error from chmod, even if the corresponding bits are already set.

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

 It could matter if you configured binfmt_misc to run .exe files
automatically using Wine as I think the permissions are checked then, just
as for native executables. It also just looks wrong to have non-executable
"exe"cutable files, but maybe the problem is in the eye of beholder here.
To summarize, in practice, it probably indeed shouldn't matter and it
should be fine to remove this line.

 OTOH if you can count on the file having correct permissions after the
first run, i.e. when it is cached, wouldn't the following:

        test -x $(cache_dir)/$@ || $(CHMOD) 750 $(cache_dir)/$@

work too?

 Regards,
VZ

pgpEjy8y6MQfT.pgp
Description: PGP signature