[tbranyen]

Because sometimes you are writing software that interacts with hardware at a root level. This is really annoying advice you're giving since its absolute and without context. No, not everything is "super dangerous" with sudo. Get that FUD outta here!

[breatheoften]

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.

[rad88]

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.

[xorcist]

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.

[breatheoften]

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?

[tbranyen]

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

[breatheoften]

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.

[saurik]

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.

[breatheoften]

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.

[diggan]

npm should never interact with hardware, it's job is to install and manage packages. I could understand that you have to run nodejs with root, since it actually can use the hardware.

But using npm with root user? I can't think of a single usecase.

[chopin]

I am not a node guy but as far as I understand nodejs is a webserver, no? _Never_ run any webserver as root. This is just bad practice.

[manigandham]

No, Node is a runtime for javascript code, using the same V8 engine from the Chrome browser. It is similar to the JVM runtime for Java code and the CLR for C#, although of course there is no intermediate compilation step for javascript.

A webserver is one of many things that can be run using Node+JS, the point being that it's an entire runtime and can do pretty much anything any other language can do.

[tbranyen]

Well think harder. Npm runs scripts from package.json. Most folks wouldn't think twice to run sudo npm start as a replacement for sudo node. I sure wouldn't think npm would start mucking with file permissions.

[diggan]

I'm sorry but that people can't figure out where to put `sudo` is not a usecase for using sudo...

Instead of running `sudo npm start`, have `scripts.start` have the value `sudo node index.js` if you want.

But then again, I'm not "most folks", I try to think when I am the root user and don't run third-party code willy-nilly when I am.

[yorwba]

The reason raw hardware access is limited to root is usually because it's "super dangerous", i.e. the consequences of your actions can be more far-reaching than usual and mistakes might have you lose more than just time.

[mbrumlow]

Right, but that means your service is running with elevated privileges, that does not mean your build tool needs too.

Furthermore if you do have a application that requires root level access then the parts that do should be isolated from the parts that don't. You don't get to just get a blank check to run as root because you need to bind to a low port.