raf wrote: > > > Not knowing the details of each user's login shell is > > > precisely the reason that ssh couldn't ever do the > > > quoting itself. > > > > The footgun is unrelated to shells. > > > > The SSH_MSG_CHANNEL_REQUEST protocol message for "exec" (RFC 4254) > > channels which are used to run a single remote command contains > > exactly one string for the command. > > > > sshd (see bottom of do_child() in session.c) runs that command string as: > > > > remote_users_shell -c command > > I'm aware of that. That's why I said what I said. > Sorry, but I don't understand what point you are making. My point wasn't directed at you specifically, rather at the thread in general. Jochen Bern wrote: > Let's summarize the general situation, though: > -- We cannot reduce the local shell's influence re: quoting to zero This happens before the ssh client process starts. > -- We cannot reduce the remote shell's influence to zero as long as > sshd(8) uses that to execute the command. As I pointed out sshd always uses the shell. (Bottom of session.c:do_child()) > -- If we avoid that and execv() the command directly, The protocol transfers a single command string to the server. The server has no array to pass to execv(). > I *could* see a "switch to remote direct execv()" *option* on the (far) > horizon, but not a change of the default behavior. I tried to make clear that the protocol does not allow such an option. > use some sort of encoding on the command transmitted from ssh to sshd The protocol message is binary transparent; it's certainly possible to serialize a data structure into the command string and use a shell on the server that deserializes its -c argument. Seems convoluted though. //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
