Sitelet https://web.archive.org/web/20201123155554/https://github.com/shelljs/shelljs/issues/495
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for execFile-like interface to exec #495

Open
nfischer opened this issue Jul 28, 2016 · 7 comments
Open

Add support for execFile-like interface to exec #495

nfischer opened this issue Jul 28, 2016 · 7 comments

Comments

@nfischer
Copy link
Member

@nfischer nfischer commented Jul 28, 2016 •

It would be great if exec had an interface, perhaps like the following:

var fileName = 'foo.txt';
exec('git', 'add', fileName);

This is great because of the following:

  • We can declare that each argument is its own non-splittable word (so fileName = 'file1.txt file2.txt' means the git call will search for one file named file1.txt file2.txt, not two separate files)
  • We can implement this fairly easily with child_process.execFile
  • This would allow us to do our own glob expansion, which would be good for Windows (Windows exec() won't glob-expand)
  • This would be useful in shx (shelljs/shx#65 & shelljs/shx#68)
  • Variables would have to be referenced as JavaScript variables just like in the rest of ShellJS, not as shell variables (exec('echo', env.PATH) vs. exec('ls $PATH')), which is the safer approach
  • Doing our own globbing means that exec will respect a call to set('-f')
  • This would give more security to shelljs-exec-proxy for the same reasons

The issue with this interface is what to do when we have only 1 argument (do we use the old behavior or the new execFile implementation?). An alternative approach is exec([arg1, arg2, arg3]), which uses a list to remove ambiguity. This is easier to parse, but perhaps not as nice to work with.


Edit: to clarify, this is a feature request, not a security vulnerability. This new API would be easier to use safely than shell.exec(), but shell.exec() is not itself vulnerable and can in fact be used safely without much difficulty (see security guidelines).

nfischer added a commit that referenced this issue Jul 3, 2018
This adds an initial implementation of shell.cmd(), which is intended as
the eventual replacement for shell.exec(). This PR does not fully
implement the API, but demonstrates a simple and secure alternative, and
will allow further iteration to cover other use cases in follow-up PRs.

Design doc: https://shelljs.page.link/cmd-design

Issue #495
Test: automated test suite
@nfischer nfischer added this to the v0.9.0 milestone Jul 12, 2018
@runk
Copy link

@runk runk commented Jan 28, 2019

@nfischer
Copy link
Member Author

@nfischer nfischer commented Jan 29, 2019

I'm still hoping to work on this. Unfortunately, it's really hard to provide reasonable behavior on Windows (#866 basically works for unix). I vaguely remember issues with v4/v5--now that we've dropped those, I need to check if this project is feasible.

@MaksPob
Copy link

@MaksPob MaksPob commented Apr 3, 2019 •

Any news for this one?
When will you fix the bug?

https://app.snyk.io/vuln/npm:shelljs:20140723

@nfischer

@nfischer
Copy link
Member Author

@nfischer nfischer commented Jun 4, 2019

No major update. This is quite difficult to get right for Windows, and I don't have a machine anymore to speed up investigation. This is something I'm very interested in solving when I have more time & resources.

nfischer added a commit that referenced this issue Jun 26, 2019
No change to logic.

This adds documentation about `shell.exec()`'s inherent vulnerability to
command injection and links to a more detailed security notice.

Issue #103, #143, #495, #810, #938, #945
nfischer added a commit that referenced this issue Jun 26, 2019
No change to logic.

This adds documentation about `shell.exec()`'s inherent vulnerability to
command injection and links to a more detailed security notice.

Issue #103, #143, #495, #765, #766, #810, #842, #938, #945
nfischer added a commit that referenced this issue Jun 26, 2019
No change to logic.

This adds documentation about `shell.exec()`'s inherent vulnerability to
command injection and links to a more detailed security notice.

Issue #103, #143, #495, #765, #766, #810, #842, #938, #945
nfischer referenced this issue Jul 8, 2019
Add a new command to launch external shell commands, providing a less vulnerable
alternative to exec(), with cross-platform globbing.

Fixes #143
@nfischer nfischer added the feature label Jul 8, 2019
@nfischer
Copy link
Member Author

@nfischer nfischer commented Jul 8, 2019

Updated the description, but this is not a security vulnerability/fix, rather this is an implementation of a feature request. Please follow #945 if you'd like to read discussion regarding how Snyk's report is misattributed.

If you're interested in being a consumer of this particular API, you're welcome to continue asking questions here (but you'll probably hear an update from me as soon as there's something to update).

nfischer added a commit that referenced this issue Oct 23, 2019
This adds an initial implementation of shell.cmd(), which is intended as
the eventual replacement for shell.exec(). This PR does not fully
implement the API, but demonstrates a simple and secure alternative, and
will allow further iteration to cover other use cases in follow-up PRs.

Design doc: https://shelljs.page.link/cmd-design

Issue #495
Test: automated test suite
nfischer added a commit that referenced this issue Oct 23, 2019
This adds an initial implementation of shell.cmd(), which is intended as
the eventual replacement for shell.exec(). This PR does not fully
implement the API, but demonstrates a simple and secure alternative, and
will allow further iteration to cover other use cases in follow-up PRs.

Design doc: https://shelljs.page.link/cmd-design

Issue #495
Test: automated test suite
nfischer added a commit that referenced this issue Oct 29, 2019
This adds an initial implementation of shell.cmd(), which is intended as
the eventual replacement for shell.exec(). This PR does not fully
implement the API, but demonstrates a simple and secure alternative, and
will allow further iteration to cover other use cases in follow-up PRs.

Design doc: https://shelljs.page.link/cmd-design

Issue #495
Test: automated test suite
nfischer added a commit that referenced this issue Oct 30, 2019
This adds an initial implementation of shell.cmd(), which is intended as
the eventual replacement for shell.exec(). This PR does not fully
implement the API, but demonstrates a simple and secure alternative, and
will allow further iteration to cover other use cases in follow-up PRs.

Design doc: https://shelljs.page.link/cmd-design

Issue #495
Test: automated test suite
@nfischer nfischer mentioned this issue Dec 4, 2019
@wmertens
Copy link

@wmertens wmertens commented Dec 5, 2019 •

I just had to look into this, and I found child_process.spawn.

It seems to me that this should be used (with shell kept false); it looks like that works on Windows too, requires arguments as an array, preventing delimiter and shell expansion issues, and it provides the output as streams, thereby fixing #979.

If it turns out that windows can't execute scripts directly, it should be just a matter of passing the shell executable as the cmd and the script as the first argument.

@nfischer
Copy link
Member Author

@nfischer nfischer commented Dec 6, 2019

I worked around those issues in #866 by using https://github.com/sindresorhus/execa, which seems to handle Windows much more nicely than anything I had figured out by hand.

That PR implemented "step 1" outlined in https://shelljs.page.link/cmd-design, but I think we'll need to implement step 2 before we can deprecate shell.exec() and ship this. If you're interested in testing out the behavior or performance of the new API, you can clone the repo and uncomment this line (just don't do this in production code until the API is actually released).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

4 participants
You can’t perform that action at this time.