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

[Jeff King <peff@peff.net>]

On Thu, Apr 11, 2013 at 12:54:34PM -0700, Junio C Hamano wrote:

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

Yeah, if we revert 96b9e0e, it would only make sense to revert the
warnings, too. Going halfway does not help anyone.

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

Yes, we would definitely be breaking them with this patch. I don't know
how common that is. As you noted, it is a bad idea security-wise (if
everything runs as "nobody", then the services are not insulated from
each other), but I can perhaps see a case where all git repos are owned
by the "git" user, but they may be accessed by different config
profiles, which are managed by $HOME.

You could still accomplish the same thing with git by setting
XDG_CONFIG_HOME, though that of course requires effort from the admin.
Sub-programs may not necessarily respect $XDG_CONFIG_HOME, though (e.g.,
anything run from a post-receive hook). On the other hand, people do not
generally push through git-daemon. But that feels like a weak argument.

-Peff