4 ms·

> Why provide an exploitable API, while a safe version is possible and is more direct? I don’t know, but my guess is that it’s mostly just history. Its to ensu

> Why provide an exploitable API, while a safe version is possible and is more direct? I don’t know, but my guess is that it’s mostly just history. Its to ensure you can take a shell oneliner and turn it into a program one liner. Ie. anything you can do in a terminal / copy from the web you can trivially do in our program! Whilst this is a footgun for application development this is a necessity for other kinds of people who write programs that are also a target market for such scripting languages. Of course it should really be called 'runInShell', and provide an option for which shell etc.

forty 5y ago
I think the author's point is that it would still pretty easy to "sh -c" yourself if needed, and at least you would have to be aware you are doing that.
- Normal_gaussian 5y ago
  The disagreement is as to who it is easy for; the author seems to only consider programmers by trade and then blame some notion of propagating a legacy of unsafe calls. Every language the author lists as vulnerable was intended, at launch, to be used both as a serious programming language as well as program launching glue or by non-career programmers for things that aren't production grade applications. The only language I can think of that is explicitly an application development language is Rust, and as the author mentions this vuln is not present. And as a note, the alternative to exec in NodeJS are keeping execFile and using these ~10 lines [1] or using spawn directly with these 216 lines [2]. I barely trust myself to reliably reproduce those. [1] https://github.com/nodejs/node/blob/df25424b9195d3122452989582a6988d1ea342a2/lib/child_process.js#L184-L229 https://github.com/nodejs/node/blob/df25424b9195d31224529895... [2] https://github.com/nodejs/node/blob/df25424b9195d3122452989582a6988d1ea342a2/lib/child_process.js#L279-L495 https://github.com/nodejs/node/blob/df25424b9195d31224529895...
  - laumars 5y ago
    The need for APIs to not have non-obvious side effects is especially important for non-career developers as they’re less likely to be aware of said side effects. So your argument is actually a strong reason for exec() not to fork /bin/sh
    - Normal_gaussian 5y ago
      You are not wrong, but this was included on the original post > Of course it should really be called 'runInShell'

forty 5y ago

I think the author's point is that it would still pretty easy to "sh -c" yourself if needed, and at least you would have to be aware you are doing that.

Normal_gaussian 5y ago
The disagreement is as to who it is easy for; the author seems to only consider programmers by trade and then blame some notion of propagating a legacy of unsafe calls. Every language the author lists as vulnerable was intended, at launch, to be used both as a serious programming language as well as program launching glue or by non-career programmers for things that aren't production grade applications. The only language I can think of that is explicitly an application development language is Rust, and as the author mentions this vuln is not present. And as a note, the alternative to exec in NodeJS are keeping execFile and using these ~10 lines [1] or using spawn directly with these 216 lines [2]. I barely trust myself to reliably reproduce those. [1] https://github.com/nodejs/node/blob/df25424b9195d3122452989582a6988d1ea342a2/lib/child_process.js#L184-L229 https://github.com/nodejs/node/blob/df25424b9195d31224529895... [2] https://github.com/nodejs/node/blob/df25424b9195d3122452989582a6988d1ea342a2/lib/child_process.js#L279-L495 https://github.com/nodejs/node/blob/df25424b9195d31224529895...
- laumars 5y ago
  The need for APIs to not have non-obvious side effects is especially important for non-career developers as they’re less likely to be aware of said side effects. So your argument is actually a strong reason for exec() not to fork /bin/sh
  - Normal_gaussian 5y ago
    You are not wrong, but this was included on the original post > Of course it should really be called 'runInShell'