[BUG] npm run changes user using default (1000) instead of root (0)

[robertsLando]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

If we have a script like "test": "node -p \"process.getuid()\"" defined in package.json when we run it with npm run test it should output 0 but it prints 1000 instead (node user). If we lunch the same command without using npm run the output is correct:

root@7f44813ba8d7:/app# node -p "process.getuid()"
0
root@7f44813ba8d7:/app# npm run test

> @app/api@0.0.1 test
> node -p "process.getuid()"

1000
root@7f44813ba8d7:/app# node -v
v16.13.2

Expected Behavior

When I run a script as root process.getuid() should return 0 even when running that script using npm run

Steps To Reproduce

Described above

Environment

• npm: 8.1.2
• Node.js: 16.13.2
• OS/System/Arch: Linux 360f89fb056b 5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7 09:18:32 UTC 2022 x86_64 GNU/Linux
• npm config:

; "user" config from /root/.npmrc

unsafe-perm = true 
user = "0" 

; node bin location = /usr/local/bin/node
; cwd = /app
; HOME = /root
; Run `npm config ls -l` to show all defaults.

I did my tests on a docker container but I was able to reproduce the issue evn outside docker

[robertsLando]

cc @wraithgar

[wraithgar]

This is the expected behavior. See #4095, #3773, #3110, and https://docs.npmjs.com/cli/v7/using-npm/scripts#user

[robertsLando]

@wraithgar Ok so that said, I need to do that without changing directoty owner as some scripts are run as sudo and others not.

Is there a way to override this someway?

[javabudd]

This is the expected behavior. See #4095, #3773, #3110, and https://docs.npmjs.com/cli/v7/using-npm/scripts#user

one of the worst changes npm could have made, stop trying to infer best security practices when most users run in a container, completely isolated from the host machine...

[ljharb]

Can you cite a source for “most”? In my experience most users run npm directly on their Mac.

[joezappie]

This causes some weird behavior when running inside a docker container with a bind mount from what I'm experiencing.

From the docs it says "When npm is run as root, scripts are always run with the effective uid and gid of the working directory owner."

My files are in a bind mount from docker, owned by a user named "torizon" with 1000:1000 in the host. Inside the container I do have a user torizon 1000:1000 but I'm weirdly running into permission denied error when trying to access a serial port /dev/ttyS1. That file has ownership of root/dialout. In both the container and host the torizon user is part of the dialout group.

Switching from root to the torizon user inside the container I no longer get the permission error:

su - torizon
$ npm start

So with npm switching users must be causing the issue in a bind mount. I've setup a 2nd container where I do not use a bind mount. In that case, npm switches to the my torizon user but it does not error out as it seems to be using the "torizon" user inside the container? Still not really sure how users/groups/permissions are passed between host/container.

This feature feels confusing by automatically doing this. I get the security aspect of it, but if npm is switching users behind the scene maybe it would be good to output that to the console?

I had no idea that it did this when ran as root and caused me to spend a few hours trying to figure out why I was getting this permission error. I thought it was a docker issue with mounting my serial adapter and wasn't even thinking that it could be npm. I finally realized it when I ran 'node server.js' and it worked.

[Macmee]

+1 for requesting a way to override this. Volume mounts in docker preserve the ownership ids from the host and so npm inferring ownership from the folder owner doesn't work very well for me.

An override would be great for containers!

If you're coming from google into this issue and want a solution, I noticed yarn doesn't (yet) try and switch users from underneath you, so you could try using that!

[wraithgar]

npm@9 also does not do this anymore.