Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Running npm as root is _super dangerous_ - full stop. npm install can run a large amount of arbitrary code downloaded from the internet via postinstall script hooks.

Its absolutely banana-pants crazy to run `npm install` as a root user in any circumstance.



It's banana-pants crazy to run npm at all. Even given all the wisdom about running as sudo, best practices etc., this team released an update where `sudo npm --help` breaks the operating system. The recklessness and confusion of ideas that indicates... postinstall hooks, I don't even want npm running. This isn't even the first such shenanigans.


If it runs untrusted code from the Internet, surely it doesn't matter much if you do it as root for most practical purposes? It could still run that spam relay, botnet software, exfiltrate your secrets and install that keylogger.


Is your argument that one is better off to run $(potentially dangerous command) with sudo privileges because it’s also risky to run it without?


NPM does more than just npm install... Not full stop. How can you talk about a tool you dont understand?


Why would you want to run any npm command with root privileges ...?

‘npm run’ seems like it would be the most tempting — but it stills seems like a bad idea ... seems to me for most problems that people are likely to use ‘npm run’ as part the solution, the developer should be able to arrange things such that they don’t need to run those npm workflows with root privileges... for other tasks where they can’t get away from the need, it still seems dangerous — it’s always dangerous to run even trusted tooling with elevated privileges...

If you do use ‘sudo npm’ $(any command) where any command is pretty much any of the forms — (even run), you are more likely to have to run additional npm command with sudo privileges at some point in future as well - you are also more likely to _have_ to run npm commands with elevated privileges in future — which is also bad because it means you are likely to be using the tools in not the best way.


Yeah, it would really suck if those files installed by my operating system--the ones that are trivially verified and easily replaced as they are literally the same on every single computer--were to be damaged. Things are much safer if I run them as the user which owns all of my data and which I spend all my time logged in as, right? I mean, at least I haven't stupidly added any part of my home directory to my path, so I can trust that the software I am running was installed by someone running as root... oh wait :/.

The only reason root even exists on a computer that has two users (root and the user that owns all the data) is to make sure that no software is installed on the system except by root. If you have things set up to also let you install software as the user that isn't root, then you have somehow missed the entire point of peiviledge separation and should just log in as root and do everything as root, as that is at that point fully equivalent.


This isn’t true with the security model employed in eg macOS.

Many places where my most important private data is stored (keychain for example) are not accessible without privilege escalation by processes running with my uid.

There of course local root exploits that exist and plenty of holes — but for many information stores on the system, I definitely want there to be an additional privilege escalation requirement for any semi-trusted code I choose to run ... furthermore overtime I want more of these personal information sources stored in a way that requires escalation — and I definitely am not going to defeat any of these future advancements prior to their release by running code with maximum system privilege for the sake of the defeatism of a previous age ... also it’s ridiculous to suggest that I am better off running untrusted code with more privileges than less — giving untrusted code maximum privileges makes everything about trying to be as practically secure as I can manage orders of magnitude harder. Running semi-trusted code with maximum privileges makes it even easier for the nefarious code to exploit me in ways I will never detect — simply by leaving more of the easy-to-write hard-to-detect exploit vectors completely unimpeded.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: