On Thu, 2013-04-11 at 01:42 -0400, Jeff King wrote:
> On Thu, Apr 11, 2013 at 05:39:43AM +0200, Mike Galbraith wrote:
> > > ALLOWED_ENV="PATH HOME"
> > > HOME=/
> > I can work around it by changing the init script to use su - git -c "bla
> > bla" to launch the thing, instead of using --user=git --group=daemon,
> > but that's just a bandaid for the busted environment setup those
> > switches were supposed to make happen, no?
> Yeah, I think the bug here is that git-daemon should be setting $HOME
> when it switches privileges with --user. Does this patch fix it for you?
> diff --git a/daemon.c b/daemon.c
> index 6aeddcb..a4451fd 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -1091,6 +1091,7 @@ static void drop_privileges(struct credentials *cred)
> if (cred && (initgroups(cred->pass->pw_name, cred->gid) ||
> setgid (cred->gid) || setuid(cred->pass->pw_uid)))
> die("cannot drop privileges");
> + setenv("HOME", cred->pass->pw_dir, 1);
> static struct credentials *prepare_credentials(const char *user_name,
> I guess that would technically break anybody who was trying to do
> something clever with HOME (i.e., point it somewhere besides --user's
> HOME where they had put some config files). But the obvious clever
> thing would be to also set the user's passwd homedir to the same place.
I did exactly that yesterday, and it didn't work, which rather surprised
me. Let me double check that I didn't screw trivial all up...
Heh, if ya don't plunk new binary into the old oddly placed bucket :)
Yeah, that works just fine.
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