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

From: Jeff King <peff@peff.net>
Date: Apr 12, 2013, 04:35 UTC
Message-ID: <20130412043501.GA12942@sigill.intra.peff.net>
In-Reply-To: <7vvc7sfkwn.fsf@alter.siamese.dyndns.org>

On Thu, Apr 11, 2013 at 09:11:20PM -0700, Junio C Hamano wrote:

> The --user option to git-daemon would be a good place to do that, I
> think.  Depending on what other "setuid to less privileged before
> running" programs do (I do not know offhand), we can say something
> like this perhaps?

That's a good question. I looked at (just sampling a few off the top of my head):

  xinetd
  openbsd-inetd
  inetutils-inetd
  postfix
  dovecot
  courier

and none of them sets HOME when dropping privileges. Admittedly some of them do not drop privileges immediately in the same way (e.g., the imap servers need to remain root so that they can switch to the right user to read mail). Postfix does set HOME, but only when actually "becoming" the user to do deliveries, not at startup.

I could also be wrong on one or more of those, as that is from some quick grepping, but I think it's clear that the norm is not to set HOME alongside setuid (of all of them, I would say git-daemon behaves most like the inetd utils, as it does not ever "become" users at all).

Show 10 quoted lines

>     --user::
> 	... current description ...
>     +
>     (Like|Unlike) many programs that let you run programs as
>     specified user, the daemon does not reset environment variables
>     such as $HOME when it runs git programs like upload-pack and
>     receive-pack. Set and export HOME to point at the home directory
>     of the user you specify with this option before you start the
>     daemon, and make sure the Git configuration files in that
>     directory is readable by that user.

So choosing "Like" here, I think this makes sense.

-Peff