npm 1.0.97 installation failing on SunOS 5.10 #1553

Closed
sergi opened this Issue Oct 14, 2011 · 10 comments

Projects

None yet

4 participants

@sergi

I am getting the following output when trying to install npm on SunOS with node 0.4.5

[jill@fhemuwal ~]$ curl http://npmjs.org/install.sh | sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6366  100  6366    0     0  84283      0 --:--:-- --:--:-- --:--:--  124k
tar=/opt/local/bin/tar
version:
tar (GNU tar) 1.25
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
fetching: http://registry.npmjs.org/npm/-/npm-1.0.97.tgz
npm-install-4127.sh: test: argument expected
It failed

Any ideas on what might be wrong?

Thanks

@isaacs
npm member

Can you run it in debug mode, like this?

curl http://npmjs.org/install.sh | npm_debug=1 bash
@sergi

Just did it. The last bit of the output shows:

npm ERR! Error: Spawn disabled for securtity reasons
npm ERR!     at ChildProcess.spawn (child_process.js:243:28)
npm ERR!     at Object.spawn (child_process.js:31:15)
npm ERR!     at spawn (/tmp/npm.6957/package/lib/utils/exec.js:103:22)
npm ERR!     at /tmp/npm.6957/package/lib/utils/tar.js:86:15
npm ERR!     at /tmp/npm.6957/package/lib/utils/mkdir-p.js:45:32
npm ERR!     at Array.forEach (native)
npm ERR!     at cb (/tmp/npm.6957/package/lib/utils/mkdir-p.js:45:9)
npm ERR!     at /tmp/npm.6957/package/lib/utils/mkdir-p.js:83:50
npm ERR!     at cb (/tmp/npm.6957/package/node_modules/graceful-fs/graceful-fs.js:36:9)
npm ERR! Report this *entire* log at:
npm ERR!     <http://github.com/isaacs/npm/issues>
npm ERR! or email it to:
npm ERR!     <npm-@googlegroups.com>
npm ERR! 
npm ERR! System SunOS 5.11
npm ERR! command "/opt/local/bin/node" "/tmp/npm.6957/package/cli.js" "install" "-gf"
npm ERR! cwd /tmp/npm.6957/package
npm ERR! node -v v0.4.5
npm ERR! npm -v 1.0.97
npm verb exit [ 1, true ]
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /tmp/npm.6957/package/npm-debug.log
npm not ok
+ ret=1
+ '[' 1 -ne 0 ']'
+ echo 'It failed'
It failed
+ exit 1
@isaacs
npm member

Ok. So... you'll never get npm to work until you get a version of node that isn't crippled. Who decided that child_process.spawn is a security problem?

I'd recommend building node from source, and never going back to wherever you got that hobbled node install from.

@isaacs isaacs closed this Oct 14, 2011
@sergi
@isaacs
npm member

The confusing thing about that error is that it's really not a security risk at all. I mean, you can run bash scripts, so it's not like you're unable to run child processes in other programs (bash, etc.), and running untrusted node programs can cause all kinds of mischief just by using fs and such. So, really, I don't know what crippling child_process.spawn actually buys you, security-wise.

@javruben

These are special binaries for the cloud9 shared run environment - where 1000s of devs connect to the same smart machine, different node process simultaneously. Hence the security concern.

@isaacs
npm member

@javruben Right, but what can a person do with child_process.spawn that is worse than what they can do with fs.write?

Security should be done at the os level, by running their node scripts as a user with strictly limited privileges, perhaps in a chroot or a zone.

@javruben

We've secured it on the os level. But allowing someone to run binary executables allows script kiddies and others to easily run rootkits and such. Soon when we have a smart machine around each running process this won't be needed anymore.

@isaacs
npm member

How would the script kiddies install a rootkit? Writing a script file is one thing, but they'd still have to get it to run with elevated perms in the first place before it could be used to execute other commands with elevated permissions.

I'm still unconvinced that any vulnerability is actually prevented by blocking child_process.spawn, which is not still possible using only fs.write. Furthermore, if you allow login shells, then they can already do anything that node's child_process.spawn can do just from bash.

@rikarends

Hi Guys,

This is just a mixup. Sergi accidentally used our shared-env solaris binary of node, which i have patched to be 'more' secure for people running code. We have done a number of things to make it harder to try binary kernel exploits. For this reason we also don't provide a real-shell but a semi-faked one. I can explain more about our set-up and security offline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment