git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Jamie Zawinski <jwz@jwz.org>
Cc: git@vger.kernel.org
Subject: Re: sharedrepository=group not working
Date: Mon, 3 Dec 2018 23:50:52 -0500	[thread overview]
Message-ID: <20181204045051.GA23351@sigill.intra.peff.net> (raw)
In-Reply-To: <53C59F2A-6D97-45F9-AF86-E255F6777E7F@jwz.org>

On Mon, Dec 03, 2018 at 08:19:12PM -0800, Jamie Zawinski wrote:

> On Dec 3, 2018, at 8:09 PM, Jeff King <peff@peff.net> 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

  parent reply	other threads:[~2018-12-04  4:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-04  3:27 sharedrepository=group not working Jamie Zawinski
2018-12-04  4:09 ` Jeff King
2018-12-04  4:19   ` Jamie Zawinski
2018-12-04  4:20     ` Jamie Zawinski
2018-12-04  4:50     ` Jeff King [this message]
2018-12-04  5:24       ` Jamie Zawinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181204045051.GA23351@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=jwz@jwz.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).