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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 12, 2013, 17:31 UTC
Message-ID: <7vr4ifejvv.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130412161600.GA20492@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 18 quoted lines

> On Fri, Apr 12, 2013 at 09:08:31AM -0700, Junio C Hamano wrote:
>
>> OK, then...
>
>> -- >8 --
>> Subject: [PATCH] doc: clarify that "git daemon --user=<user>" option does not export HOME=~user
>
> I'd add this motiviation to the body of the commit message:
>
>   The fact that we don't set $HOME may confuse admins who
>   expect $HOME/.gitconfig to be respected. And worse, since
>   96b9e0e3, a git-daemon started by root is likely to fail
>   to run at all, as the user we switch to generally cannot
>   read ~root.
>
> This still feels ugly, like we are documenting some gotcha
> that is going to hit most admins, when we could be helping
> them in the code.

I agree that it feels a bit wrong to sound as if we are blaming the messanger (the one that notices a possible misconfiguration), but you are correct that we should make a note on why we think it is a good idea to add this piece of extra documentation in the history.

Will add the above before queuing.

Show 9 quoted lines

> One option we have not explored is an environment variable
> to loosen git's requirement. I'm thinking something like
> GIT_INACCESSIBLE_HOMEDIR_OK, which could be set by default
> when git-daemon uses --user.
>
> That would leave all existing setups working, but would
> still enable the extra protections for people not running
> git-daemon (and people who use git via sudo could choose to
> set it, too, if they would prefer that to setting up HOME).

Perhaps.

Right now, the only case people noticed was that we complain when the effective user cannot even tell if config file(s) exists or not. Labelling this option as "Treat unreable as missing" is fine, but "an inaccessible homedir is OK" is vastly different. Imagine a new version where we start _requiring_ something to exist (and we read from it) and imagine further that the expected place of that thing is somewhere inside $HOME. We cannot keep the promise to those who set "an inaccessible homedir is OK" option when that happens, as we may need that piece of information we wanted to read from there in order to properly operate.

In any case, I think the loosening is an independent issue.