Re: [lmi] Unexpected git (mis)behavior

[Vadim Zeitlin]

On Fri, 13 Nov 2020 14:53:10 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 11/13/20 12:56 AM, Vadim Zeitlin wrote:
[...most of the discussion snipped...]
GC> > GC> I would have thought that that subdirectory would have had group=user
GC> > GC> permissions because
GC> > GC>   $git config --get-all core.sharedrepository
GC> > GC>   1
GC> > GC> but clearly it didn't.
GC> > 
GC> >  Yes, and this remains a mystery to me...
GC> 
GC> I have long thought that core.sharedrepository does less than one
GC> might hope, as discussed here in March 2020:
GC>   
https://lists.nongnu.org/archive/cgi-bin/namazu.cgi?query=sharedrepository&submit=Search&idxname=lmi

 Yes, this might well be true... But while I don't remember any more which
umask do you use on this server, setting it to (just) 2 would ensure that
all new directories are created group-writable without any cooperation from
Git. So maybe this could be a solution?

GC> > GC> Should I make some appropriate hook (post-checkout, perhaps) do this:
GC> > GC>   sudo chgrp -R lmi /opt/lmi
GC> > GC>   sudo find /opt/lmi -type d -exec chmod g+s {} +
GC> > GC>   sudo chmod -R g=u /opt/lmi
GC> > GC> in order to enforce those rules after every pull, so that this problem
GC> > GC> can't occur again?
GC> > 
GC> >  Normally it should never occur in the first place, so there should be no
GC> > need to correct it like this. I'd be curious if the command
GC> > 
GC> >   find /opt/lmi/src/lmi '!' -group lmi -o '(' -type d -a '!' -perm g+s ')'
GC> > 
GC> > returns any files right now?
GC> 
GC> Yes, that returns thousands of files. One of the results
GC> (retyped manually here) is
GC>   drwxrwsr-x. 2 [MY REDACTED ID] lmi ... aclocal
GC> which has group lmi, is a directory, and has an 's' permission,
GC> so the command isn't doing what I thought it would; I'll have to
GC> take another look at it later when I feel less sleepy.

 Sorry, this will teach me trying to show off by writing "find" commands
without looking at the man page :-( The last predicate should have been
"-perm -g+s", with the extra "-" because "-perm -mode" checks that "these
permissions are set", rather than just "-perm mode" which checks that "the
permissions are exactly equal to mode" which is almost never what is wanted
(as the man page helpfully indicates).

 Also, the mode itself should probably be "g+ws", as the directories must
be writable and not just have the SGID bit set.


 Sorry again for wasting your time,
VZ

pgplHN22HjaWX.pgp
Description: PGP signature