Everything is super dangerous as root, one should avoid using root at all costs until there is no other way.
NPM's awfulness notwithstanding, it's trivial to write a shell script to do what you say and add a symlink to ~/bin. But everyone on StackOverflow will tell each other "just run it with sudo", and they do, and then quickly move on with their lives (presumably to be followed with "and break things"). Instead of doing the right thing, raising their hackles about how poorly NPM is designed, and holding its community leaders accountable.
1. https://github.com/Microsoft/TypeScript/blob/b29e0c9e3ab2471...
I'm sure you are now going to tell me there is an easy way to fix that too, and I'd be happy if there was, but for me I just want to use npm to install a program or two.
I don't think I've ever seen the install instructions for a npm-packaged tool actually say to do this.
I don't think you're introducing new information. When I wrote my original comment, it was intended to fully acknowledge that this is what's at play. And rereading it, seems like it does that well enough, but I might be wrong.
But in any case, I'll run it with sudo then, is absolutely the wrong thing to do, regardless of the bad choices on NPM's part—on par with I just want to use my online banking, so I'll click through this certificate error, or I just want to take some notes, so I'll grant this mobile app the full permissions it's asking for.
There's a reason I used the phrase "normalization of deviance". It's a phrase that came out of post mortem investigations into simple process failures at NASA that led to proper (catastrophic, life-ending) failures, and an urge to find an answer to the question, "how in the world did we get here?"
If they fixed that, 99% of these issues would go away. This is actually an example of something from the node universe working better on Windows.
thats not right. you've just got npm setup wrong. https://docs.npmjs.com/getting-started/fixing-npm-permission...
It's extra-frustrating writing those instructions, because not only are they platform-specific, but they are different depending on what the user has already done to their system. If some other tool told them to create ~/.bash_profile or ~/.bash_login, the more shell-agnostic option of modifying ~/.profile will no longer work.
Figuring out where to change the PATH is also confusing, and you might come across solutions that seem to work, but cause weird errors later down the road. For example, the tool being unavailable when invoked remotely, because you only changed the PATH for interactive shells.
It's understandable that people use sudo when they don't see it causing any obvious problems. Installing user-local packages should be one simple command, and it's a failure of operating systems and package managers that it's not. As it stands, correct usage is much harder than incorrect usage, and this is the result.
But using npm with root user? I can't think of a single usecase.
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.
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.
Its absolutely banana-pants crazy to run `npm install` as a root user in any circumstance.
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.
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.
‘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.
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.