On Mon, Dec 03, 2018 at 08:19:12PM -0800, Jamie Zawinski wrote: > On Dec 3, 2018, at 8:09 PM, Jeff King <peff@xxxxxxxx> wrote: > > > > but it works fine. Might there be some effective-uid trickiness with the > > way the server side of git is invoked? Or is this a network mount where > > the filesystem uid might not match the process uid? > > Huh. 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.) Yeah, I think we can discount any oddness there. > The 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...) Hrm. I don't think group permissions would even matter. We asked to mkdir() with 0700 anyway, so we know they'd be zero. But a funny umask does seem like a likely candidate for causing the problem. We asked for 0700, but if there were bits set in umask (say, 0200 or something), that would restrict that further. And it would explain what you're seeing (inability to write into a directory we just created), and it might have worked with previous versions (which was less strict on the group permissions). I don't suppose this is leaving those incoming-* directories sitting around so we can inspect their permissions (it's suppose to clean them up, so I doubt it). If you're up for it, it might be interesting to patch Git to inspect the umask and "ls -l" the objects/ directory at the problematic moment. The interesting point is when we call into tmp-objdir.c:setup_tmp_objdir(). -Peff
