[XorNot]

So this doesn't strike me as an npm issue but something more fundamental: there is no easy way on any platform to define a set of rules for processes I invoke via the command line.

Like, it would be really really nice if I could wrap npm so it can only write to $HOME/.npm, /tmp and the current working directory - but I know of no system which will currently let me do that suitably dynamically.

[Sanddancer]

Sudo and ACLs. There's a lot of power in there under the hood that a lot of people don't think of with these types of problems. For your specific use case, I'd start by creating a new user, something like $USER-npm-install. Next, I'd set acls on $HOME/.npm to allow write access with setfacl, something like setfacl -m u:$USER-npm-install:rwx $HOME/.npm .

For the actual script, I'd have it check to make sure that the current working directory is owned by you, then have it setfacl -m u:$USER-npm-install:rwx . to temporarily give the installer user access, then do sudo -u $USER-npm-install npm install Whatever . After it's done, I'd do sudo chown -R $USER . to get everything owned by you, and setfacl -m u:$USER-npm-install:--- . to revoke the permissions until needed for next time.

If my brain were suitably in gear, I'd give more than a 20000 foot view of what needs to be done, but those are the basics. A lot of people think of sudo as just being something for getting to root, but it is rather useful for creating sandboxed users for potentially dangerous actions as well. Create a user with just enough privileges to do what needs to be done, and have fun.

[viraptor]

Selinux, apparmor, tomoyo, rbac already do this. They will need some configuration though if you want to use them with binaries in your home directory.

[eyko]

Unix user permissions take care of that.

[namuol]

Kinda. It would be nicer to limit permissions on a per-"application" level, requiring one-time explicit grants from the user, kinda like how a lot of platforms already do it (web browsers, Android APK, etc).

[eyko]

> It would be nicer to limit permissions on a per-"application" level, requiring one-time explicit grants from the user

Most services run under their own username/group for exactly this reason. A user should only be able to obliterate their `$HOME` folder and nothing else, and if you run npm as a certain user, you can restrict that even further by setting the right permissions. If you still need further protection from accidental deletions, it's probably a good idea to use a filesystem with snapshot support like ZFS or BTRFS.

Very few programs should be run as root, and developers should know this. Random scripts pulled from the internet are not in that list. If you absolutely need to be logged in as root, then it's probably best you run npm as a different user (runuser -l username -c command). I cannot imagine any reason why you would need to run `npm install` as root. Global packages? Perhaps users should chmod their global npm modules folder to allow installing as an unprivileged user, or at least as the npm user, and then run npm as that user. My global npm packages folder is owned by the npm user/group and if I need to install a global npm package, i usually run it as `runuser -l npm -c npm install -g ...` (or sudo -u npm on osx). It's not an extreme precaution and it's not even a hassle, and while I understand it's not the default, it's also not true that by default npm install can write or delete files outside of your home folder (unless run as root)

I'm not sure the title of this should be "npm install could be dangerous" more than "running scripts as root could be very dangerous", which is a no-brainer. The rule of thumb for users/admins in unix-like systems is to keep permissions as strict as possible.

[XorNot]

The problem is this doesn't tally well with the overall user experience.

I don't want my hard drive being littered with files owned by not-me, because they don't work properly when I need to rsync things and I can't change their ownership easily etc.

What I want is a kind of "sub-user": where I have sudo like powers over files owned by my user account by default, which are then dropped for individual commands - or something similar.

Which comes back to my original point: we've lots of mechanisms, but none of them actually wrap-well or seamlessly with how you actually work which makes them too much of a pain to use for the 99% of the time when everything is fine.