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 11, 2013, 19:54 UTC
Message-ID: <7vwqs8hmh1.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130411181439.GA2820@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 26 quoted lines

> On Thu, Apr 11, 2013 at 11:11:03AM -0700, Jonathan Nieder wrote:
>
>> > -- >8 --
>> > Subject: [PATCH] daemon: set HOME when we switch to --user
>> 
>> Thanks for taking care of it.  For what it's worth,
>> 
>> Acked-by: Jonathan Nieder <jrnieder@gmail.com>
>> 
>> I'm not sure whether to keep 96b9e0e (config: treat user and xdg
>> config permission problem as errors) in the long run, BTW.  There have
>> been multiple reports about dropping privileges and not being able to
>> access the old HOME, and I'm not convinced any more that the
>> predictability is worth the breakage for such people.  Though checking
>> if $HOME is inaccessible and treating that case specially would be
>> even worse...
>> 
>> Insights welcome.
>
> I could go either way. I think 96b9e0e is the right thing to do
> conceptually, but I kind of doubt it was affecting all that many people.
> And though it's _possible_ for it to be a security problem, I find it
> much more likely that the site admin tries to set some config, gets
> annoyed when it doesn't work, and debugs it. So from a practical
> perspective, 96b9e0e may be doing more harm than good, even though it's
> the right thing.

Recent reports in this thread make us think so, I guess.

But reverting 96b9e0e alone would not help these people very much though. They will have reams of warning messages in their server logs, and the way to "fix" it would be the same as the way to work around the access_or_die(), namely, to set $HOME to point at a more appropriate place before running "git daemon".

I also have a suspicion that your patch makes things worse for people who are more adept at these issues around running daemons than the people who introduced this problem in the first place (eh, that's "us"). It is plausible that they may run multiple instances of "initially root but setuid() to an unprivileged user" daemons, giving each of them a separate play area by setting $HOME to different values, just for management's ease not necessarily for security (hence sharing the same unprivileged user), which will be broken by the patch that unconditionally overrides $HOME.

A trade off to make things slightly easier for one sysadmin by making another thing impossible to do for another sysadmin does not sound like a good one.