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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html