-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] npm
refuses to run if the home directory is inaccessible
#4769
Comments
Not sure if this related, but I also have an issue with a nonroot user not being able to run npm cli for v8.6.0 and above. (Working for v8.5.5). NPM crashes (?) with new line returned with error code 254. However, I am still having permission issues for the logs: |
When npm is run by a user without a home folder, the home folder is set to This is the "normal" behaviour, even for older versions of npm not affected by this issue.
Note: If we run the same command with the latest npm version, we get the crash with exit code 243:
The issue was introduced in 8.6.0, specifically by cc6c094.
This looks to be a permission issue, since npm is not allowed to create a folder in the system root folder. I guess the behaviour introduced in cc6c094 is fine but I don't think it's a good idea to fallback to @lukekarrys any thoughts? |
I stumbled upon the same issue today. My docker containers are being run using AWS Lambda. The trick by creating a Declaring the Is there a global config to disable the logging instead having to add |
This is a very surprising change! It also breaks read-only container filesystems. |
We're experiencing the same issue when the user's home directory exists but is not accessible (trying to access it results in error code EACCES/13). npm 8.5.5 logs some warnings and keeps going. npm 8.11.1 dies with exit code 243 (it calls Node 16.15.1, Linux, inside Docker. |
npm
refuses to run if a home directory does not existnpm
refuses to run if a home directory is inaccessible
npm
refuses to run if a home directory is inaccessiblenpm
refuses to run if the home directory is inaccessible
this seems related to #4838 also. i believe the fix will be able to be applied to both |
Hoping this might help someone: I am using the standard Node Docker images (https://hub.docker.com/_/node/) with security config as per https://snyk.io/blog/10-best-practices-to-containerize-nodejs-web-applications-with-docker/ - the pertinent part being running under the It turns out that Cloud Build sets/overrides the The "fix" is to override what Cloud Build sets the environment var to in each Build step which uses
Anyway, as I say, I hope that helps someone. I have raise the issue with Google and am hoping they'll stop setting the env var which causes the problem - and also, obviously would be good for |
Fix image not running in K8s (ROSA) Trying to solve the container exiting with error code `243`. `npm` throws `243` for any command you try to run with it. Here is how to get into the container while the entrypoint normally errors. ``` $ oc run -i --tty --image=ghcr.io/matrix-org/matrix-public-archive/matrix-public-archive:sha-65edaea1a9713bb2cc93fa98638327fdeff765cd mpa-test2 --port=3050 --restart=Never --env="DOMAIN=cluster" --command /bin/bash $ npm start $ echo $? 243 ``` Why does the same image work in Docker? ``` $ docker run -it --entrypoint /bin/bash ghcr.io/matrix-org/matrix-public-archive/matrix-public-archive:sha-65edaea1a9713bb2cc93fa98638327fdeff765cd $ npm start # it starts ✅ ``` ## Root cause Seems like it could be either of these issues. Both are `8.6.0`+ problems as well which lines up with the `npm` version available in each base image. - npm/cli#4769 - npm/cli#4996 - Specific comment about breaking stuff in k8s for other people, npm/cli#4996 (comment)
Hi all, NPM developers, This bug has been reported in April. It has obvious security implications. Thanks for your great work on NPM, a crucial piece of infrastructure. Cheers, |
@dokterbob what are the security implications? I see none. |
@ljharb As a workaround, we are fixing npm version to 8.5.5 in order to run in production with a read-only filesystem. However, there is detected vuln for this version: CVE-2022-29244 If there is a workaround for the current bug, so that we can bump version to the latest npm, it would be very much appreciated. Thanks |
@marcchanwork thats not the security implications of this bug, though. |
This also changes all the log messages about not being able to create initial directories and files to `log.verbose` since we know run those commands on init. There are a lot of valid reasons why those might fail, and we don't want to show a warning for them every time. Fixes: #4769 Fixes: #4838 Fixes: #4996
This also changes all the log messages about not being able to create initial directories and files to `log.verbose` since we know run those commands on init. There are a lot of valid reasons why those might fail, and we don't want to show a warning for them every time. Fixes: #4769 Fixes: #4838 Fixes: #4996
This also changes all the log messages about not being able to create initial directories and files to `log.verbose` since we know run those commands on init. There are a lot of valid reasons why those might fail, and we don't want to show a warning for them every time. Fixes: #4769 Fixes: #4838 Fixes: #4996
This also changes all the log messages about not being able to create initial directories and files to `log.verbose` since we know run those commands on init. There are a lot of valid reasons why those might fail, and we don't want to show a warning for them every time. Fixes: #4769 Fixes: #4838 Fixes: #4996
This also changes all the log messages about not being able to create initial directories and files to `log.verbose` since we know run those commands on init. There are a lot of valid reasons why those might fail, and we don't want to show a warning for them every time. Fixes: #4769 Fixes: #4838 Fixes: #4996
This also changes all the log messages about not being able to create initial directories and files to `log.verbose` since we know run those commands on init. There are a lot of valid reasons why those might fail, and we don't want to show a warning for them every time. Fixes: #4769 Fixes: #4838 Fixes: #4996
This also changes all the log messages about not being able to create initial directories and files to `log.verbose` since we know run those commands on init. There are a lot of valid reasons why those might fail, and we don't want to show a warning for them every time. Fixes: #4769 Fixes: #4838 Fixes: #4996
This also changes all the log messages about not being able to create initial directories and files to `log.verbose` since we know run those commands on init. There are a lot of valid reasons why those might fail, and we don't want to show a warning for them every time. Fixes: #4769 Fixes: #4838 Fixes: #4996
Sorry for belated reply. The security implications is that one is required to give npm write access to the home directory. We can't apply the principle of least privilege this way. For example, we can't run npm with a nonexistent home directory, or without any write access to the FS for that matter. (Great to see this seems to be solved.) |
Is it possible that there was a regression on this? I am on NPM 9.8.1 (from Fedora repos) and are seeing this exact problem when running npm install as a user without a home directory. |
same from the official deb source. |
Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
Currently happens on npm 8.6.0 and later. Attempting to run any npm command if the user's home directory does not exist (possible for system-only Linux users) makes npm exit without having output anything (well, it does output a newline) and returns with an error code of 243.
Expected Behavior
npm commands should work as expected. Even basic commands, such as showing the version (
npm -v
) provide no output and also exit with the aforementioned error code.Steps To Reproduce
sudo adduser --system --no-create-home test
)The following shell logs demonstrate the issue. Reproduction done in a Debian docker container to avoid spinning up a whole VM just to test this with a clean slate.
Environment
; npm config -ls returns no output.
The text was updated successfully, but these errors were encountered: