[BUG] npm exits silently with the code 254 and read only filesystem

[svsool]

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

I use npm 8.6.0 and when I exec into Kubernetes pod and run npm --version npm exits silently. Then running echo $? prints 254. It used to work fine with npm 8.5.5, read only file system and mentioned below security context config.

Expected Behavior

I expect that npm --version will run fine.

Steps To Reproduce

1. Create a static pod in the Kubernetes cluster using the following yaml:

apiVersion: v1
kind: Pod
metadata:
  name: node-test
spec:
  containers:
  - name: node-test-pod
    image: node:18.0.0-alpine
    command:
    - tail
    - "-f"
    - /dev/null
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - AUDIT_WRITE
          - CHOWN
          - DAC_OVERRIDE
          - FOWNER
          - FSETID
          - KILL
          - MKNOD
          - NET_BIND_SERVICE
          - NET_RAW
          - SETFCAP
          - SETGID
          - SETPCAP
          - SETUID
          - SYS_CHROOT
      privileged: false
      readOnlyRootFilesystem: true <------ this is important to reproduce a bug
      runAsNonRoot: true
      runAsUser: 1000

2. Run kubectl exec -it <pod_name> -- /bin/sh
3. Run npm --version
4. It should fail silently

Environment

• npm: 8.6.0
• Node.js: v18.0.0
• OS Name: Alpine Linux v3.15
• System Model Name:
• npm config:

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

[wraithgar]

npm logging was changed recently to open the logfile early and stream to it, rather than wait for errors. To disable this completely use the flag --max-logs=0. Please try this and see if it solves this issue.

The logging code is supposed to gracefully handle this situation but it appears to not be doing so in your case. Can you also try running with --loglevel silly to see what happens? Usually a WARN message should happen:

$ npm -v 
npm WARN logfile could not be created: Error: EACCES: permission denied, open '/Users/wraithgar/.npm/_logs/2022-05-03T20_27_46_794Z-debug-0.log'
8.8.0

[XhmikosR]

I'm also hitting this. Indeed, the issue happens only in docker.

I had to pin down the Node.js image to v16.15.0 which ships with npm v8.5.5, but using Node.js v16.15.1 with npm v8.5.5 also worked fine. I also tried npm v8.12.1 and the same error happens.

If someone could look into it, I'd really appreciate it!

[darcyclarke]

@XhmikosR did you try @wraithgar's suggested fix?

[whs]

Doesn't seems to do anything

node@pod:/usr/local/app$ npm --max-logs=0 --loglevel silly

node@pod:/usr/local/app$ echo $?
254

[jasonwilliams]

@wraithgar's fix didn't work for me I still get 254 just like @whs does. Node 18.1.0, npm 8.8.0

[XhmikosR]

OK, so this very weird. I just tried it today and it works in most projects except for the ones we have npm install warnings which seem to be now errors with the new version.

I'll give it a go again, but I could reproduce the failure in 4 separate machines yesterday. I'll try to pinpoint the failure and see if the npm peer dependencies issues are now errors instead of warnings (the repos are Angular apps which have the issue #3666).

[mhamann]

We just hit this as well. Had to pin Node.js to v16.15.0 so we get npm v8.5.5. This is a critical issue given that it's strongly recommended to run production workloads on a read-only filesystem.

[bkatiemills]

Fixing to npm 8.5.5 is a no-go for us in light of CVE-2022-29244.

[thw0rted]

Just to close the loop for anyone who was watching this, the root cause was

#4996 -- failed to output a useful message when denied permission to open a log

and the reason people encountered it in Docker was

nodejs/docker-node#1734 -- image runs as root by default, and a recent change to npm behavior causes it to run as the owner of the working directory when launched by root, but the host-OS user ID does not exist in the container, resulting in a read failure (triggering the above)