{"thread":{"id":"49943","subject":"sharedrepository=group not working","startedAt":"2018-12-04T03:35:31Z","lastAt":"2018-12-04T05:24:55Z","messageCount":6,"participants":["Jamie Zawinski","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"364526","messageId":"F9365CBF-3D2D-4A05-AC0D-4604067B5826@jwz.org","threadId":"49943","inReplyTo":null,"subject":"sharedrepository=group not working","fromName":"Jamie Zawinski","fromEmail":"jwz@jwz.org","sentAt":"2018-12-04T03:27:13Z","receivedAt":"2018-12-04T03:35:31Z","isPatch":false,"sender":{"key":"jwz@jwz.org","avatar":"https://gravatar.com/avatar/4662d154ace3ae8e1be4f6a4ff85c0287390c6d9aa62aba53bbd66c09e3164f2?d=mp&s=160"},"body":"I think sharedrepository=group stopped working some time between 2.10.5 (works) and 2.12.4 (does not). 2.19.2 also does not.\n\nI have a user trying to push to a shared repo; the user is not the owner of the files but it is in the same group. All the repo files are g+rw and all the repo directories are g+srw.\n\n\tdrwxrwsr-x. 252 jwz cvs 4096 Dec 3 18:53 /cvsroot/dna.git/objects/\n\nI am getting:\n\n\terror: remote unpack failed: unable to create temporary object directory\n\tTo /cvsroot/dna.git\n\t ! [remote rejected] master -> master (unpacker error)\n\nIf I'm reading this strace right, it looks like git is successfully creating a directory under objects/ and then failing to create a subdirectory of it (maybe because the just-created parent directory ended up with the wrong permissions?)\n\n mkdir(\"./objects/incoming-U5EN8D\", 0700 \n <... mkdir resumed> ) = 0\n rt_sigaction(SIGINT, {0x56a860, [INT], SA_RESTORER|SA_RESTART, 0x7f842cb3b2f0}, \n <... rt_sigaction resumed> {SIG_IGN, [], 0}, 8) = 0\n rt_sigaction(SIGHUP, {0x56a860, [HUP], SA_RESTORER|SA_RESTART, 0x7f842cb3b2f0}, {SIG_DFL, [], 0}, 8) = 0\n rt_sigaction(SIGTERM, {0x56a860, [TERM], SA_RESTORER|SA_RESTART, 0x7f842cb3b2f0}, {SIG_DFL, [], 0}, 8) = 0\n rt_sigaction(SIGQUIT, {0x56a860, [QUIT], SA_RESTORER|SA_RESTART, 0x7f842cb3b2f0}, {SIG_DFL, [], 0}, 8) = 0\n rt_sigaction(SIGPIPE, {0x56a860, [PIPE], SA_RESTORER|SA_RESTART, 0x7f842cb3b2f0}, {SIG_DFL, [PIPE], SA_RESTORER|SA_RESTART, 0x7f842cb3b2f0}, 8) = 0\n mkdir(\"./objects/incoming-U5EN8D/pack\", 0777) = -1 EACCES (Permission denied)\n\n\n--\nJamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/\n\n"},{"id":"364527","messageId":"20181204040903.GA17059@sigill.intra.peff.net","threadId":"49943","inReplyTo":"F9365CBF-3D2D-4A05-AC0D-4604067B5826@jwz.org","subject":"Re: sharedrepository=group not working","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-12-04T04:09:03Z","receivedAt":"2018-12-04T04:09:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 03, 2018 at 07:27:13PM -0800, Jamie Zawinski wrote:\n\n> I think sharedrepository=group stopped working some time between\n> 2.10.5 (works) and 2.12.4 (does not). 2.19.2 also does not.\n\nHmm. Given the time-frame and the fact that your strace shows problems\nwriting into the objects/incoming-* directory, it's likely caused by\n722ff7f876 (receive-pack: quarantine objects until pre-receive accepts,\n2016-10-03).\n\nThe big change there is that instead of writing directly into objects/,\nwe create a temporary objects/incoming-* directory, write there, and\nthen migrate the objects over after we determine they're sane.\n\nSo in your strace we see the temp directory get created:\n\n> mkdir(\"./objects/incoming-U5EN8D\", 0700 \n> <... mkdir resumed> ) = 0\n\nThe permissions are tighter than we ultimately want, but that's OK.\nThis tempdir is just for this process (and its children) to look at, and\nthen we'd eventually migrate the files out.\n\nI could definitely imagine there being a bug in which we don't then\nproperly loosen permissions when we move things out of the tempdir, but\nwe don't even get that far. We fail immediately:\n\n> mkdir(\"./objects/incoming-U5EN8D/pack\", 0777) = -1 EACCES (Permission denied)\n\nThat seems strange. The outer directory is only 0700, but the user\npermissions should be sufficient. Even with the g+s bit set, it should\nstill be owned by the same user, shouldn't it?\n\nI tried reproducing your state like this:\n\n git init --bare dst.git\n git -C dst.git config core.sharedrepository group\n chgrp -R somegroup dst.git\n find dst.git -type f | xargs chmod g+rw\n find dst.git -type d | xargs chmod g+srw\n\n # push works from original user\n git clone dst.git client\n (\n cd client &&\n git commit --allow-empty -m foo\n git push\n )\n\n # push works from alternate user\n sudo su anotheruser sh -c '\n git clone dst.git /tmp/other &&\n cd /tmp/other &&\n git commit --allow-empty -m foo &&\n git push --receive-pack=\"strace -e mkdir git-receive-pack\"\n '\n\nbut it works fine. Might there be some effective-uid trickiness with the\nway the server side of git is invoked? Or is this a network mount where\nthe filesystem uid might not match the process uid?\n\n-Peff\n"},{"id":"364528","messageId":"53C59F2A-6D97-45F9-AF86-E255F6777E7F@jwz.org","threadId":"49943","inReplyTo":"20181204040903.GA17059@sigill.intra.peff.net","subject":"Re: sharedrepository=group not working","fromName":"Jamie Zawinski","fromEmail":"jwz@jwz.org","sentAt":"2018-12-04T04:19:12Z","receivedAt":"2018-12-04T04:19:17Z","isPatch":false,"sender":{"key":"jwz@jwz.org","avatar":"https://gravatar.com/avatar/4662d154ace3ae8e1be4f6a4ff85c0287390c6d9aa62aba53bbd66c09e3164f2?d=mp&s=160"},"body":"On Dec 3, 2018, at 8:09 PM, Jeff King wrote:\n> \n> but it works fine. Might there be some effective-uid trickiness with the\n> way the server side of git is invoked? Or is this a network mount where\n> the filesystem uid might not match the process uid?\n\nHuh. They're on the same ext4 fs (it's an AWS EBS sc1 volume, but I think that still counts as \"not a network mount\" as far as Linux is concerned.)\n\nThe way I was seeing this fail was a CGI invoking \"git push\", as user \"httpd\" (and I verified that when the cgi was invoked, \"groups\" reported that \"httpd\" was a member of group \"cvs\") but when I tried to reproduce the error with \"sudo -u apache git push\" it didn't fail. So possibly something hinky is going on with group permissions when httpd invokes git, but I did verify that whoami, groups and pwd were as expected, so I couldn't tell what that might be... (Oh, I didn't check what umask was, but it should have been 022...)\n\n--\nJamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/\n\n"},{"id":"364529","messageId":"1C20022B-666C-4E55-B8F7-43DDA9EBA107@jwz.org","threadId":"49943","inReplyTo":"53C59F2A-6D97-45F9-AF86-E255F6777E7F@jwz.org","subject":"Re: sharedrepository=group not working","fromName":"Jamie Zawinski","fromEmail":"jwz@jwz.org","sentAt":"2018-12-04T04:20:57Z","receivedAt":"2018-12-04T04:21:00Z","isPatch":false,"sender":{"key":"jwz@jwz.org","avatar":"https://gravatar.com/avatar/4662d154ace3ae8e1be4f6a4ff85c0287390c6d9aa62aba53bbd66c09e3164f2?d=mp&s=160"},"body":"On Dec 3, 2018, at 8:19 PM, Jamie Zawinski wrote:\n> \n> (Oh, I didn't check what umask was, but it should have been 022...)\n\nTypo, I mean to say 002.\n\n--\nJamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/\n\n"},{"id":"364530","messageId":"20181204045051.GA23351@sigill.intra.peff.net","threadId":"49943","inReplyTo":"53C59F2A-6D97-45F9-AF86-E255F6777E7F@jwz.org","subject":"Re: sharedrepository=group not working","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-12-04T04:50:52Z","receivedAt":"2018-12-04T04:50:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 03, 2018 at 08:19:12PM -0800, Jamie Zawinski wrote:\n\n> On Dec 3, 2018, at 8:09 PM, Jeff King wrote:\n> > \n> > but it works fine. Might there be some effective-uid trickiness with the\n> > way the server side of git is invoked? Or is this a network mount where\n> > the filesystem uid might not match the process uid?\n> \n> Huh. They're on the same ext4 fs (it's an AWS EBS sc1 volume, but I\n> think that still counts as \"not a network mount\" as far as Linux is\n> concerned.)\n\nYeah, I think we can discount any oddness there.\n\n> The way I was seeing this fail was a CGI invoking \"git push\", as user\n> \"httpd\" (and I verified that when the cgi was invoked, \"groups\"\n> reported that \"httpd\" was a member of group \"cvs\") but when I tried to\n> reproduce the error with \"sudo -u apache git push\" it didn't fail. So\n> possibly something hinky is going on with group permissions when httpd\n> invokes git, but I did verify that whoami, groups and pwd were as\n> expected, so I couldn't tell what that might be... (Oh, I didn't check\n> what umask was, but it should have been 022...)\n\nHrm. I don't think group permissions would even matter. We asked to\nmkdir() with 0700 anyway, so we know they'd be zero.\n\nBut a funny umask does seem like a likely candidate for causing the\nproblem. We asked for 0700, but if there were bits set in umask (say,\n0200 or something), that would restrict that further. And it would\nexplain what you're seeing (inability to write into a directory we\njust created), and it might have worked with previous versions (which\nwas less strict on the group permissions).\n\nI don't suppose this is leaving those incoming-* directories sitting\naround so we can inspect their permissions (it's suppose to clean them\nup, so I doubt it). If you're up for it, it might be interesting to\npatch Git to inspect the umask and \"ls -l\" the objects/ directory at the\nproblematic moment. The interesting point is when we call into\ntmp-objdir.c:setup_tmp_objdir().\n\n-Peff\n"},{"id":"364531","messageId":"903E1F42-3911-471D-B754-7592A5FD2CC7@jwz.org","threadId":"49943","inReplyTo":"20181204045051.GA23351@sigill.intra.peff.net","subject":"Re: sharedrepository=group not working","fromName":"Jamie Zawinski","fromEmail":"jwz@jwz.org","sentAt":"2018-12-04T05:24:51Z","receivedAt":"2018-12-04T05:24:55Z","isPatch":false,"sender":{"key":"jwz@jwz.org","avatar":"https://gravatar.com/avatar/4662d154ace3ae8e1be4f6a4ff85c0287390c6d9aa62aba53bbd66c09e3164f2?d=mp&s=160"},"body":"On Dec 3, 2018, at 8:50 PM, Jeff King wrote:\n> \n> I don't suppose this is leaving those incoming-* directories sitting\n> around so we can inspect their permissions (it's suppose to clean them\n> up, so I doubt it). If you're up for it, it might be interesting to\n> patch Git to inspect the umask and \"ls -l\" the objects/ directory at the\n> problematic moment. The interesting point is when we call into\n> tmp-objdir.c:setup_tmp_objdir().\n\nThe problem was that Apache was setting my umask to 113! With that:\n\n+ ls -ldF ./objects/incoming-w7agmb/pack objects/incoming-w7agmb\nls: cannot access ./objects/incoming-w7agmb/pack: Permission denied\ndrw---S--- 2 apache cvs 4096 Dec 3 21:14 objects/incoming-w7agmb/\nerror: remote unpack failed: unable to create temporary object directory\n\nWith 002 it succeeds:\n\n+ ls -ldF ./objects/incoming-IbGS6h/pack objects/incoming-IbGS6h\ndrwx--S--- 3 apache cvs 4096 Dec 3 21:19 objects/incoming-IbGS6h/\ndrwxrwsr-x 2 apache cvs 4096 Dec 3 21:19 ./objects/incoming-IbGS6h/pack/\n\nSo I fixed my umask and got it working, but maybe a test for \"your umask is dumb\" is worthwhile.\n\nThanks for your help!\n\n--\nJamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/\n\n"}]}