Paolo Bonzini [off-list ref] writes:
quoted
quoted
But it's harmless to have both.
Considering the fact that daemon authors might not get pointed at their
mistakes as soon as possible, it is harmful to try and hide those facts.
Agree. OTOH what about opening fd's 0/1/2 to /dev/null only in
git-shell.c, now that it's not a builtin anymore?
Hmm, why git-shell?
It is either run by ssh (via command="" option in authorized_keys file),
by init/login (if in /etc/passwd), or by gitosis (and its equivalent).
Wouldn't these callers already give it a sane environment (and if a
lookalike to gitosis forgets to do so, wouldn't Stephen's argument not to
hide the issue from the daemon writers apply)?
It is either run by ssh (via command="" option in authorized_keys file),
by init/login (if in /etc/passwd), or by gitosis (and its equivalent).
It is possible to run it with file descriptors closed via ssh, using
command="git-shell 0<&- 1<&- 2<&-" in the authorized_keys file.
It's true that in this case the user is also shooting himself, but given
that git-shell is used to restrict operation to "safe" commands, this
special case might be worth being worked around.
Paolo
Paolo Bonzini wrote:
quoted
It is either run by ssh (via command="" option in authorized_keys file),
by init/login (if in /etc/passwd), or by gitosis (and its equivalent).
It is possible to run it with file descriptors closed via ssh, using
command="git-shell 0<&- 1<&- 2<&-" in the authorized_keys file.
I don't consider this that relevant, however...
It's true that in this case the user is also shooting himself, but given
that git-shell is used to restrict operation to "safe" commands, this
special case might be worth being worked around.
Since a programmer error in this case doesn't inflict just pain on the
user, but also is a potential security leak that can potentially be
exploited by third party users, things are different, and it is worth
catering for.
--
Sincerely,
Stephen R. van den Berg.
"Listen carefully, I shall say this only wence."