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