Johannes Sixt <johannes.sixt@xxxxxxxxxx> wrote:
> There are 2 reason, *not* to do this:
>
> 1. It's not needed. You can use
>
> /usr/local/bin/git --exec-path=/usr/local/bin daemon --inetd ...
>
> to inject the exec-path.
Don't need the `exec-path': git knows the right one already. So this is
entirely equivalent to my suggestion, except that the user has to jump
through this stupid hoop.
Besides, I don't want to run `git' from inetd -- it makes distinguishing
things in /etc/hosts.deny harder. Unless I write wrapper scripts or make
symlinks for everything, I suppose, but doesn't it seem mad to invent
wrapper scripts to distinguish between things which are already distinct
but glommed together for some strange reason.
> 2. Security. Those inetds launder the environment for a reason. Assume inetd
> sets PATH=/usr/bin:/bin and git-daemon is installed
> as /usr/sbin/git-daemon. With your patch now all hooks run with the path
> set to /usr/sbin:/usr/bin:/bin.
Yes, of course. Silly me. It's much better that the service fail to
work at all than that it have something strange like /usr/local/bin on
its PATH.
Besides, the only things git-daemon will actually run are
git-upload-pack, upload-archive and receive-pack.
* git-upload-pack in turn runs git-pack-objects, which is a builtin
and therefore runs setup_path in main. Anything that does will
therefore certainly have the same evil on its PATH as would have
been inserted by my patch -- though I don't think it actually execs
anything else.
* git-upload-archive is another builtin, so the same applies; again, I
don't think it actually execs anything else.
* git-receive-pack is not something you enable if you care about
security anyway.
Besides, if there /are/ scripts and so on run by git-daemon, then
they'll be hook scripts, and will also fail if the Git tools aren't on
the PATH.
Your argument, if I might stoop to caricature, seems to be `No, we
mustn't have git-daemon set up the path itself -- it might actually
/work/.'
-- [mdw]
-
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
