4 ms·

> hidden argv join It is not hidden. It is written down in plain sight: A complete command line may be specified as command, or it may have additional argum

> hidden argv join It is not hidden. It is written down in plain sight: A complete command line may be specified as command, or it may have additional arguments. If supplied, the arguments will be appended to the command, separated by spaces, before it is sent to the server to be executed. - third line in `man 1 ssh`

chubot 1y ago
It's hidden in the sense that it creates ambiguity at the usage site. Compare with sudo: $ sudo ls 'file with spaces' ls: cannot access 'file with spaces': No such file or directory If ssh (and sh eval) did not accept multiple arguments, then this wouldn't even get to ls: $ ssh example.com ls 'file with spaces' ls: cannot access 'file': No such file or directory ls: cannot access 'with': No such file or directory ls: cannot access 'spaces': No such file or directory Accepting argv is better. Or forcing this is better: $ ssh example.com "ls 'file with spaces'" So it's clear it's a single shell string. Accepting a shell string is sometimes OK, but silently joining multiple args is useless, and insecure. "RTFM" is not a good answer when security is involved.
- blueflow 1y ago
  This stubborn attitude to refuse to consult the documentation at all and then expect the tool to work according to your preconceptions. Tools do have rough edges, if you don't want to learn about them, you will get bitten.
  - chubot 1y ago
    It’s a design mistake because it adds exactly zero functionality. The only thing it adds is insecurity. If the feature didn’t exist, then it wouldn’t need to be documented, and the world would be better.
    - blueflow 1y ago
      [flagged]
      - chubot 1y ago
        I think you missed the original point, which is that joining argv is equivalent to sh -c "$1 $2 $3 $4 ..." This is a form of shell injection, just like sh -c "ls $dir" because there's interpolation WITHOUT escaping. That should be: dir=$(escape "$dir") sh -c "ls $dir" Or simply ls "$dir" It's not my preconception -- it's a security problem. It's similar to ShellShock -- you can argue it was documented behavior, but it's still a security problem.
        blueflow 1y ago
        The interpolation is not the security problem, the problem is the user not quoting their data. It's similar to curl CWE-93[1], where it was documented and in-use behavior and consequently was rejected as a security problem. Example for ssh: ssh host ls "$(quote "$dir")" [1] https://hackerone.com/reports/3133379 https://hackerone.com/reports/3133379
        Filligree 1y ago
        And yet it keeps happening. An engineering field grows up when people stop assigning blame, and start searching for solutions.
        blueflow 1y ago
        I just posted one way how to do it correctly. And research (aka: consulting the manpage) is an essential part of engineering. Doing that would also solve the problem.
        immibis 1y ago
        No, the problem is that even if you quote your data, ssh unquotes it, so you have to quote it twice.
  - nothrabannosir 1y ago
    This statement can be true without contradicting anything anyone said upstream. Otherwise could use it to justify just about any bad design decision. Yes it’s in the docs. Yes people who carefully read the docs won’t get bitten. Also yes the design could be improved so people don’t make this mistake even without reading the docs. Both things can be true. We’re currently only talking about the latter, though.
    - blueflow 1y ago
      > We’re currently only talking about the latter, though. I'm surprised, as i started this subthread explicitly to contest that the argv join is "hidden".
  - immibis 1y ago
    This very stubborn attitude to defend a bad design because it's documented. Bugs can be fixed.
    - blueflow 1y ago
      It is bad design, but your idea of something does not make anything non-conforming a bug.
  - pwdisswordfishz 1y ago
    > Tools do have rough edges, if you don't want to learn about them, you will get bitten. I presume you consider INTERCAL to be a sanely designed programming language.
    - blueflow 1y ago
      I'm not defending SSH's design, im criticizing peoples unwillingness to learn about the design as it is so they can work around it. Edit: The INTERCAL handbook is a great read, and despite being satirical, it is more detailed and qualified than the documentation of some other popular projects.
scbrg 1y ago
That's honestly not particularly clear. It doesn't say the command will be invoked by a shell on the remote host. Sure the whole "separated by spaces" thing sorta implies it will, as spaces don't mean much to anything but a shell, but it's still fairly vague. In fact, later on the man page only mentions a shell in the part that talks about the behavior when no additional arguments are given: When the user's identity has been accepted by the server, the server either executes the given command in a non-interactive session or, if no command has been specified, logs into the machine and gives the user a normal shell as an interactive session. The wording "executes the given command" would generally not imply "I'll just throw it at $SHELL and see what happens". A few lines later it gets even more confusing: The session terminates when the command or shell on the remote machine exits and all X11 and TCP connections have been closed. ...which I definitely would say suggests that either a shell is executed or the command supplied as argument to ssh. That it means "command as interpreted by a shell on the remote host" is far from obvious.
- blueflow 1y ago
  > The wording "executes the given command" would generally not imply "I'll just throw it at $SHELL and see what happens". "command" means exactly that. Evaluation by shell. With that in mind, the manual page should read less ambiguous to you. I actually don't have a good source for that, but you can check the execve(2) manpage. If command would refer to the execution of an argument vector, it would have been mentioned in there. The other meaning of "command" refers to specific programs like those in /bin.

chubot 1y ago

It's hidden in the sense that it creates ambiguity at the usage site. Compare with sudo: $ sudo ls 'file with spaces' ls: cannot access 'file with spaces': No such file or directory If ssh (and sh eval) did not accept multiple arguments, then this wouldn't even get to ls: $ ssh example.com ls 'file with spaces' ls: cannot access 'file': No such file or directory ls: cannot access 'with': No such file or directory ls: cannot access 'spaces': No such file or directory Accepting argv is better. Or forcing this is better: $ ssh example.com "ls 'file with spaces'" So it's clear it's a single shell string. Accepting a shell string is sometimes OK, but silently joining multiple args is useless, and insecure. "RTFM" is not a good answer when security is involved.

blueflow 1y ago
This stubborn attitude to refuse to consult the documentation at all and then expect the tool to work according to your preconceptions. Tools do have rough edges, if you don't want to learn about them, you will get bitten.
- chubot 1y ago
  It’s a design mistake because it adds exactly zero functionality. The only thing it adds is insecurity. If the feature didn’t exist, then it wouldn’t need to be documented, and the world would be better.
  - blueflow 1y ago
    [flagged]
    - chubot 1y ago
      I think you missed the original point, which is that joining argv is equivalent to sh -c "$1 $2 $3 $4 ..." This is a form of shell injection, just like sh -c "ls $dir" because there's interpolation WITHOUT escaping. That should be: dir=$(escape "$dir") sh -c "ls $dir" Or simply ls "$dir" It's not my preconception -- it's a security problem. It's similar to ShellShock -- you can argue it was documented behavior, but it's still a security problem.
      - blueflow 1y ago
        The interpolation is not the security problem, the problem is the user not quoting their data. It's similar to curl CWE-93[1], where it was documented and in-use behavior and consequently was rejected as a security problem. Example for ssh: ssh host ls "$(quote "$dir")" [1] https://hackerone.com/reports/3133379 https://hackerone.com/reports/3133379
        Filligree 1y ago
        And yet it keeps happening. An engineering field grows up when people stop assigning blame, and start searching for solutions.
        blueflow 1y ago
        I just posted one way how to do it correctly. And research (aka: consulting the manpage) is an essential part of engineering. Doing that would also solve the problem.
        immibis 1y ago
        No, the problem is that even if you quote your data, ssh unquotes it, so you have to quote it twice.
- nothrabannosir 1y ago
  This statement can be true without contradicting anything anyone said upstream. Otherwise could use it to justify just about any bad design decision. Yes it’s in the docs. Yes people who carefully read the docs won’t get bitten. Also yes the design could be improved so people don’t make this mistake even without reading the docs. Both things can be true. We’re currently only talking about the latter, though.
  - blueflow 1y ago
    > We’re currently only talking about the latter, though. I'm surprised, as i started this subthread explicitly to contest that the argv join is "hidden".
- immibis 1y ago
  This very stubborn attitude to defend a bad design because it's documented. Bugs can be fixed.
  - blueflow 1y ago
    It is bad design, but your idea of something does not make anything non-conforming a bug.
- pwdisswordfishz 1y ago
  > Tools do have rough edges, if you don't want to learn about them, you will get bitten. I presume you consider INTERCAL to be a sanely designed programming language.
  - blueflow 1y ago
    I'm not defending SSH's design, im criticizing peoples unwillingness to learn about the design as it is so they can work around it. Edit: The INTERCAL handbook is a great read, and despite being satirical, it is more detailed and qualified than the documentation of some other popular projects.

scbrg 1y ago

That's honestly not particularly clear. It doesn't say the command will be invoked by a shell on the remote host. Sure the whole "separated by spaces" thing sorta implies it will, as spaces don't mean much to anything but a shell, but it's still fairly vague. In fact, later on the man page only mentions a shell in the part that talks about the behavior when no additional arguments are given: When the user's identity has been accepted by the server, the server either executes the given command in a non-interactive session or, if no command has been specified, logs into the machine and gives the user a normal shell as an interactive session. The wording "executes the given command" would generally not imply "I'll just throw it at $SHELL and see what happens". A few lines later it gets even more confusing: The session terminates when the command or shell on the remote machine exits and all X11 and TCP connections have been closed. ...which I definitely would say suggests that either a shell is executed or the command supplied as argument to ssh. That it means "command as interpreted by a shell on the remote host" is far from obvious.

blueflow 1y ago
> The wording "executes the given command" would generally not imply "I'll just throw it at $SHELL and see what happens". "command" means exactly that. Evaluation by shell. With that in mind, the manual page should read less ambiguous to you. I actually don't have a good source for that, but you can check the execve(2) manpage. If command would refer to the execution of an argument vector, it would have been mentioned in there. The other meaning of "command" refers to specific programs like those in /bin.