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

Jeff King [off-list ref] writes:

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

quoted

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.

Thanks for checking.

For $HOME, it is sufficient to do an unsetenv-equivalent, and I
suspect some of them do just that, though.  Vanilla openbsd-inetd
doesn't, but Debian seems to have a patch to sanitize the
environment, for example.

But still...

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

quoted

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

I would prefer the simplicity ;-)

"Set and export HOME to point at the home directory of the user you
specify with this option" screams that it wants to be rephrased at
me, though.  It somehow sounds as if this option is a way to set and
export the environment variable unless re-read carefully X-<.

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

quoted

quoted

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

I would prefer the simplicity ;-)

"Set and export HOME to point at the home directory of the user you
specify with this option" screams that it wants to be rephrased at
me, though.  It somehow sounds as if this option is a way to set and
export the environment variable unless re-read carefully X-<.

Perhaps:

  Like many programs that switch user id, the daemon does not reset
  environment variables such a `$HOME` when it runs git programs like
  `upload-pack` and `receive-pack`. When using this option, you may also
  want to set and export `HOME` to point at the home directory of
  `<user>` before starting the daemon, and make sure the Git
  configuration file in that directory are readable by `<user>`.

I tried to address your concern above (which I agree with), smooth over
a few clunky wordings, and use "<user>", which is defined in the heading
of the option:

  --user=<user>, --group=<group>

-Peff

On Fri, 2013-04-12 at 01:05 -0400, Jeff King wrote: 

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

quoted

quoted

quoted

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

I would prefer the simplicity ;-)

"Set and export HOME to point at the home directory of the user you
specify with this option" screams that it wants to be rephrased at
me, though.  It somehow sounds as if this option is a way to set and
export the environment variable unless re-read carefully X-<.

Perhaps:

  Like many programs that switch user id, the daemon does not reset
  environment variables such a `$HOME` when it runs git programs like
  `upload-pack` and `receive-pack`. When using this option, you may also
  want to set and export `HOME` to point at the home directory of
  `<user>` before starting the daemon, and make sure the Git
  configuration file in that directory are readable by `<user>`.

I tried to address your concern above (which I agree with), smooth over
a few clunky wordings, and use "<user>", which is defined in the heading
of the option:

  --user=<user>, --group=<group>

I just updated my local rpm to set HOME, so the surprise of no workee
after upgrade here is forever gone.  Looks like suses (at least)
packagers will need to do the same, else canned setup ain't gonna work.

-Mike

On Fri, Apr 12, 2013 at 01:05:50AM -0400, Jeff King wrote:

  Like many programs that switch user id, the daemon does not reset
  environment variables such a `$HOME` when it runs git programs like
  `upload-pack` and `receive-pack`. When using this option, you may also
  want to set and export `HOME` to point at the home directory of
  `<user>` before starting the daemon, and make sure the Git
  configuration file in that directory are readable by `<user>`.

How about "and make sure any Git configuration files", since there
might not be any Git configuration files.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

On Fri, Apr 12, 2013 at 07:26:36AM -0400, W. Trevor King wrote:

On Fri, Apr 12, 2013 at 01:05:50AM -0400, Jeff King wrote:

quoted

  Like many programs that switch user id, the daemon does not reset
  environment variables such a `$HOME` when it runs git programs like
  `upload-pack` and `receive-pack`. When using this option, you may also
  want to set and export `HOME` to point at the home directory of
  `<user>` before starting the daemon, and make sure the Git
  configuration file in that directory are readable by `<user>`.

How about "and make sure any Git configuration files", since there
might not be any Git configuration files.

Yeah, that is better. Thanks.

-Peff