Re: regression: "96b9e0e3 config: treat user and xdg config permission problems as errors" busted git-daemon

From: Jeff King <peff@peff.net>
Date: Apr 12, 2013, 19:58 UTC
Message-ID: <20130412195854.GA7795@sigill.intra.peff.net>
In-Reply-To: <7vr4ifcytk.fsf@alter.siamese.dyndns.org>

On Fri, Apr 12, 2013 at 12:51:19PM -0700, Junio C Hamano wrote:

Show 11 quoted lines

> >> If the access() failed due to ENOENT, the caller will get a negative
> >> return from this function and will treat it as "ok, it does not
> >> exist", with the original or the updated code.  This new case is
> >> treated the same way by the existing callers, i.e. pretending as if
> >> there is _no_ file in that unreadable $HOME directory.
> >
> > Exactly.
> 
> The explanation you are replying to was meant to illustrate how this
> is not "inaccessible is OK", but is "treat inaccessible as missing",
> by the way.

Ah, I see the distinction you were making. Yes, that is what I was thinking (and what the patch does); I just used the word "OK" instead.

Show 6 quoted lines

> Well, at least to me, the documentation update was never about
> "oops, we broke it", but was about "be careful where the HOME you
> are using actually is" from the beginning of the suggestion.  I was
> actually planning to apply it to maint-1.8.1 that predates the xdg
> stuff, and that is why the text only suggests to set HOME for the
> config.

Yes; I think the only change needed would be to the commit message I proposed (if you even picked that up; I didn't look).

Show 14 quoted lines

> > Do you have an opinion on just dropping the environment variable
> > completely and behaving this way all the time? It would "just fix" the
> > cases people running into using su/sudo, too.
> 
> With the tightening, people who used --user=daemon, expecting that
> they can later tweak the behaviour by touching ~daemon/.gitconfig,
> got an early warning that they need to set HOME themselves, but with
> any variant of the patch under discussion, as long as loosening is
> on by default, will no longer get that benefit.
> 
> I am not yet convinced if that is a real "fix/cure".
> 
> So, no, I have not even reached the point where I can form an
> opinion if this behaviour should be the default.

OK. I'll hold off for now while we stew on it. Jonathan's patch looks OK to me, but it has the same issue. But I think every path has to be one of:

  1. We annoy sysadmins who need to take an extra step to handle the
     HOME situation with --user (the current behavior, or any other
     proposal that they have to opt into).

  2. We annoy sysadmins who want to set HOME with --user, either by
     making what they want to do impossible, or making them set an extra
     variable or option to accomplish what used to work (my patch to set
     HOME with --user).

  3. We loosen the check, so some cases which might be noteworthy are
     not caught (my patch, Jonathan's patch, etc).

I think any solution will have to fall into one of those slots. So we need to pick the least evil one, and then hammer out its least evil form.

-Peff