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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> 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.