https://bugzilla.mindrot.org/show_bug.cgi?id=2283
Colin Watson <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #6 from Colin Watson <[email protected]> --- (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. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
