{"action":"created","issue":{"url":"https://api.github.com/repos/npm/npm/issues/19883","repository_url":"https://api.github.com/repos/npm/npm","labels_url":"https://api.github.com/repos/npm/npm/issues/19883/labels{/name}","comments_url":"https://api.github.com/repos/npm/npm/issues/19883/comments","events_url":"https://api.github.com/repos/npm/npm/issues/19883/events","html_url":"https://github.com/npm/npm/issues/19883","id":299211682,"number":19883,"title":"Critical Linux filesystem permissions are being changed by latest version","user":{"login":"Crunkle","id":1208758,"avatar_url":"https://avatars3.githubusercontent.com/u/1208758?v=4","gravatar_id":"","url":"https://api.github.com/users/Crunkle","html_url":"https://github.com/Crunkle","followers_url":"https://api.github.com/users/Crunkle/followers","following_url":"https://api.github.com/users/Crunkle/following{/other_user}","gists_url":"https://api.github.com/users/Crunkle/gists{/gist_id}","starred_url":"https://api.github.com/users/Crunkle/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Crunkle/subscriptions","organizations_url":"https://api.github.com/users/Crunkle/orgs","repos_url":"https://api.github.com/users/Crunkle/repos","events_url":"https://api.github.com/users/Crunkle/events{/privacy}","received_events_url":"https://api.github.com/users/Crunkle/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":61,"created_at":"2018-02-22T03:41:27Z","updated_at":"2018-02-22T14:37:18Z","closed_at":null,"author_association":"NONE","body":"#### I'm opening this issue because:\r\n\r\n  - [ ] npm is crashing.\r\n  - [ ] npm is producing an incorrect install.\r\n  - [x] npm is doing something I don't understand.\r\n  - [x] Other (_see below for feature requests_):\r\n\r\n#### What's going wrong?\r\n\r\nThis issue has been happening ever since 5.7.0 was released a few hours ago. It seems to have completely broken my filesystem permissions and caused me to have to manually fix the permissions of critical files and folders. I believe that it is related to the commit 94227e1 which is traversing and running `chown` on the wrong, often critical, filesystem files and folders.\r\n\r\nBy running `sudo npm` under a non-root user (root users do not have the same effect), filesystem permissions are being heavily modified. For example, if I run `sudo npm --help` or `sudo npm update -g`, both commands cause my filesystem to change ownership of directories such as `/etc`, `/usr`, `/boot`, and other directories needed for running the system. It appears that the ownership is recursively changed to the user currently running npm.\r\n\r\nI found that a selection of directories in `/` were owned by a non-root user after running `sudo npm` and many binaries in `/usr/bin` stopped working as their permissions were changed. People experiencing this bug will likely have to fully reinstall their system due to this update.\r\n\r\n`npm update -g` as `root`:\r\n\r\nNo output, all packages up to date. Likely still causes a `chown` to be run silently to `root:root`.\r\n`drwxr-xr-x 10 root root 129 Feb 22 03:39 /usr`\r\n\r\nThen doing a `su jared` (a non-root user):\r\n\r\n`sudo npm update -g` as `jared`:\r\n\r\nSometimes `EACCES` or `EPERM` output, almost always corrupts the filesystem.\r\n`drwxr-xr-x 10 jared jared 129 Feb 22 03:39 /usr`\r\n\r\nThe `/usr` directory has been claimed by `npm` and ownership was set to `jared:jared` as shown above. This same thing happens with other directories seemingly at random whilst being traversed.\r\n\r\nIf you do not give it `sudo` permissions and just run `npm` alone, you can see it is attempting to traverse my `/boot` ownership and crashes when it fails (if given `sudo`, it will say `chown` instead of `scandir` and output an `EACCES` instead):\r\n\r\n> Error: EPERM: operation not permitted, scandir '/boot/initramfs-linux-fallback.img'\r\n> TypeError: Cannot read property 'get' of undefined\r\n> ...\r\n\r\n> Error: EACCES: operation not permitted, chown '/boot/initramfs-linux-fallback.img'\r\n> TypeError: Cannot read property 'get' of undefined\r\n> ...\r\n\r\nIt is very dangerous to run the latest version under `sudo` and I have a feeling it isn't just me getting these results.\r\n\r\n#### How can the CLI team reproduce the problem?\r\n\r\nI am personally using Arch Linux with the latest `npm` package, installed as the `root` user via:\r\n\r\n`pacman -Sy npm nodejs`\r\n`npm install -g npm`\r\n`npm install -g semver`\r\n\r\nEnsure that your npm is on version 5.7.0 then, as a non-root user, with `sudo` prefix:\r\n\r\n`sudo npm --help`\r\n\r\nYou will find that it fails, sometimes with no warnings and sometimes with an `EACCES` as it is unable to `chown` the files in `/boot` or read-only directories. No log files are generated on my system as it throws an output in console.\r\n\r\nThis was _not_ occurring on my system before the most recent update and using 5.6.0 resolves the issue entirely.\r\n\r\n### Supporting Information:\r\n\r\n - `npm -v` prints: `5.7.0`\r\n - `node -v` prints: `9.5.0`\r\n - `npm config get registry` prints: `https://registry.npmjs.org/`\r\n - Windows, OS X/macOS, or Linux?: Arch Linux (latest base)\r\n - Network issues:\r\n   - Geographic location where npm was run: UK\r\n   - [ ] I use a proxy to connect to the npm registry.\r\n   - [ ] I use a proxy to connect to the web.\r\n   - [ ] I use a proxy when downloading Git repos.\r\n   - [ ] I access the npm registry via a VPN\r\n   - [ ] I don't use a proxy, but have limited or unreliable internet access.\r\n - Container:\r\n   - [ ] I develop using Vagrant on Windows.\r\n   - [ ] I develop using Vagrant on OS X or Linux.\r\n   - [ ] I develop / deploy using Docker.\r\n   - [ ] I deploy to a PaaS (Triton, Heroku)."},"comment":{"url":"https://api.github.com/repos/npm/npm/issues/comments/367700107","html_url":"https://github.com/npm/npm/issues/19883#issuecomment-367700107","issue_url":"https://api.github.com/repos/npm/npm/issues/19883","id":367700107,"user":{"login":"ignasg","id":12294040,"avatar_url":"https://avatars0.githubusercontent.com/u/12294040?v=4","gravatar_id":"","url":"https://api.github.com/users/ignasg","html_url":"https://github.com/ignasg","followers_url":"https://api.github.com/users/ignasg/followers","following_url":"https://api.github.com/users/ignasg/following{/other_user}","gists_url":"https://api.github.com/users/ignasg/gists{/gist_id}","starred_url":"https://api.github.com/users/ignasg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ignasg/subscriptions","organizations_url":"https://api.github.com/users/ignasg/orgs","repos_url":"https://api.github.com/users/ignasg/repos","events_url":"https://api.github.com/users/ignasg/events{/privacy}","received_events_url":"https://api.github.com/users/ignasg/received_events","type":"User","site_admin":false},"created_at":"2018-02-22T14:37:18Z","updated_at":"2018-02-22T14:37:18Z","author_association":"NONE","body":"Having a system test on a few docker images and checking if they are bootable post install could be an automated way to prevent a similar disaster in the future, but that might be a bit of an overreaction."}}
{"actor":{"display_login":"ignasg"}}