also sprach Joey Hess <jo...@debian.org> [2014-04-17 21:20 +0200]: > > % setfacl -R -m mask::rwX,group:pm:rwX shared.git > > % setfacl -R -d -m mask::rwX,group:pm:rwX shared.git > > I don't understand all this ACL stuff[1]. Is this bug report about file > permissions, or about ACLs? AFAIK, git's core.sharedRepository does > not involve ACLs.
I think this bug is about enforcing file modes, group membership and ACLs, thereby overriding policies in place governing their defaults. I don't think this has anything to do with ACLs. The behaviour is identical between g+s mode and ACLs, which are actually related. So if we fix one, we probably fix the other. > I am resorting to reading the tea leaves here -- still nothing in > this bug report that I am able to clearly understand -- but it > seems likely that what you are having trouble with is rsync or > cp's behavior of copying the source file modes/group to the > destination file. Yes, rsync/cp are enforcing the mode/ownership/group membership/ACL data from the source onto the destination, which I don't think they should. In addition, git annex creates directories without honouring the default policies, I think. > git-annex has not used rsync -a, which would preserve the group, > for a long time if ever. But for local-to-local repositories, it still > uses cp -a. > > Suggest you use git annex --debug to find the command it's running. I did, and indeed, there's a cp -a invocation, which is a shame. What is not shown in the debug output are the invocations of mkdir(). For instance, there's [2014-04-20 08:56:38 CEST] call: cp ["--reflink=auto","-a","/git/photos.git/annex/objects/137/6dd/SHA256E-s20752896--f3b70f5fbf0a59bcda044645240f181a67e232734b420feb4fe05c2fdf5d2f72.ARW/SHA256E-s20752896--f3b70f5fbf0a59bcda044645240f181a67e232734b420feb4fe05c2fdf5d2f72.ARW","/destination/photos/.git/annex/tmp/SHA256E-s20752896--f3b70f5fbf0a59bcda044645240f181a67e232734b420feb4fe05c2fdf5d2f72.ARW"] which is all good and well, but then, the temporary file is renamed to .git/annex/objects/Xp/JJ/SHA… in this case. git annex creates those hash directories (which is not shown in the debug output), using wrong permissions, before it moves the file to its final destination (also not shown). Unfortuately, git annex also uses Git plumbing in such a way that the post-checkout hook does not get called after a sync (which arguably is a checkout-like operation, especially with --content). Therefore, the usual hacks to fix permissions required when using Git cannot be used either. > [1] I decided a long time ago to add ACLs to the "too complicated to try > to use pile" next to SELinux, and this has always seemed like a good > decision. You seem to be in the fortunate situation not having to share files on a filesystem between accounts. -- .''`. martin f. krafft <madduck@d.o> Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems "they that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- benjamin franklin
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
