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.

-Mike 


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

Reply via email to