[Bug 2094] New: Executing commands via ssh on a remote host has different parameter passing properties

[bugzilla-daemon at mindrot.org]

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

            Bug ID: 2094
           Summary: Executing commands via ssh on a remote host has
                    different parameter passing properties
    Classification: Unclassified
           Product: Portable OpenSSH
           Version: 6.2p1
          Hardware: Other
                OS: OpenBSD
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: laurie at tratt.net

Consider the file /tmp/ap.sh which simply prints out all the arguments
to it:

  #! /bin/sh

  while [ $# -ge 1 ]; do
      echo "arg: $1"
      shift
  done

If I create a C file ex_local.c:

  #include <unistd.h>

  int main(int argc, char** argv) {
      execlp(argv[1], argv[1], "a", "a'b", NULL);
      return 0;
  }

and then compile and run it, the arguments passed to it are printed
out:

  $ ex_local /tmp/ap.sh
  a
  a'b
  $

which is correct. If I have this C file ex_ssh.c:

  #include <unistd.h>

  int main(int argc, char** argv) {
      execlp("/usr/bin/ssh", "/usr/bin/ssh", argv[1], argv[2], "a",
"a'b", NULL);
      return 0;
  }

and run it:

  $ ex_ssh somehost.com /tmp/ap.sh
  zsh:1: unmatched '

then /tmp/ap.sh isn't even executed on the remote machine. This
surprised me, because (perhaps naively), I expected parameters passed
to a command to work identically whether that command is local or run
via ssh. Just to show that it isn't the fault of zsh on the remote
machine, other shells show the same problem even with a simpler version
of the escaping problem:

  $ echo ls \'
  '
  $ ssh someotherhost.com echo ls \'
  bash: -c: line 0: unexpected EOF while looking for matching `''
  bash: -c: line 1: syntax error: unexpected end of file

The basic problem, as far as I can tell, is that ssh is passing
arguments as unprotected strings to the remote shell to execute the
command. In essence, "funny" characters (e.g. ') are being reevaluated
remotely, even though they would not locally.

Assuming I have got the right end of the stick so far (which is no by
no means guaranteed), it's not obvious to me what the best behaviour
should be. When a user executes a command via ssh, there is a soft
notion that a login shell will be executed, with the users normal
customisation, before the command is executed. I presume this is what
ssh is doing at the moment, and where the parameter problem occurs. The
only way I can see for arguments to be passed reliably is for ssh to
invoke a middle-man command which then execv's with precisely the
parameters passed to ssh itself. This might be rather heavy-weight for
most uses, and will break backwards compatibility (some people are
bound to have inadvertently come to rely on the current behaviour):
perhaps it could be enabled via an optional switch?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.