[Bug 2283] option to execute command without shell

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2283

Colin Watson <cjwatson at debian.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cjwatson at debian.org

--- Comment #6 from Colin Watson <cjwatson at debian.org> ---
(In reply to Darren Tucker from comment #3)
> That's not a use case.  I'm looking for an example of something that
> could be done with what you're asking for but can't be done other
> ways.

The thing that is straight-up impossible with OpenSSH's current
facilities is to reliably invoke a command with non-trivial arguments
on the server when you don't know the user's login shell.  If you know
the shell, then you can always reverse its quoting algorithm (well, as
long as the shell is at least moderately sensible), but if you're
building a general program that uses ssh as a building block then you
can't rely on this, even if you can rely on having OpenSSH at both
ends.

This is an important omission.  Still, I'd argue it's the wrong bar to
set.  Quoting is notoriously hard to get right, especially when OpenSSH
barely documents its current behaviour at all.  sshd(8) says that "all
commands are run under the user's login shell", but that's as far as it
goes; ssh(1) makes no mention of the command execution behaviour
whatsoever, even neglecting to mention the "join arguments with spaces"
thing which is specifically something that the ssh client does.

But even if it were properly documented (an unusual omission for
OpenSSH, really), at the risk of trying to teaching you how to suck
eggs, part of building secure systems is having clear APIs that are
hard to get wrong, and OpenSSH's current command execution API is
neither clear nor straightforward.  Essentially every modern
programming language has realised for some time that it needs to
provide a clear way to pass separate arguments in its local command
execution API; OpenSSH is a long way behind here.  I understand that
it's mainly a protocol failure and not OpenSSH's fault as such, aside
from the documentation problems, but OpenSSH doesn't seem like a
terrible place to start either.

I wonder if there's some hope of coming up with something that could be
standards-track, so that OpenSSH isn't stuck with something
non-standard forever?  Perhaps something like this as an extension to
the connection protocol:

  byte      SSH_MSG_CHANNEL_REQUEST
  uint32    recipient channel
  string    "exec-list"
  boolean   want reply
  string[]  arguments

... together with a behaviour specification, probably indicating that
the first argument should be looked up in the system's search path as
the command and that the remaining arguments should be passed to it in
such a way that the command sees them as separate arguments.  (Unix
servers could use execvp; Windows servers would have to do their own
quoting such that a call to CommandLineToArgvW in the subprocess will
do the right thing, or something along those lines.)

As Paul says, use of this would have to be governed by a client-side
option, and various other bits and pieces: using it unconditionally if
the server advertised support for it would certainly break
compatibility in cases where people have relied on the current quoting
semantics.  It would be a while before we could rely on this even in
OpenSSH-only environments.  But being able to have reliable quoting in
five years would still be a lot better than never having it.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.