Critical Linux filesystem permissions are being changed by latest version

[Crunkle]

I'm opening this issue because:

• [ ] npm is crashing.
• [ ] npm is producing an incorrect install.
• [x] npm is doing something I don't understand.
• [x] Other (see below for feature requests):

What's going wrong?

This 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.

By 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.

I 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.

npm update -g as root:

No output, all packages up to date. Likely still causes a chown to be run silently to root:root. drwxr-xr-x 10 root root 129 Feb 22 03:39 /usr

Then doing a su jared (a non-root user):

sudo npm update -g as jared:

Sometimes EACCES or EPERM output, almost always corrupts the filesystem. drwxr-xr-x 10 jared jared 129 Feb 22 03:39 /usr

The /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.

If 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):

Error: EPERM: operation not permitted, scandir '/boot/initramfs-linux-fallback.img' TypeError: Cannot read property 'get' of undefined ...

Error: EACCES: operation not permitted, chown '/boot/initramfs-linux-fallback.img' TypeError: Cannot read property 'get' of undefined ...

It is very dangerous to run the latest version under sudo and I have a feeling it isn't just me getting these results.

How can the CLI team reproduce the problem?

I am personally using Arch Linux with the latest npm package, installed as the root user via:

pacman -Sy npm nodejs npm install -g npm npm install -g semver

Ensure that your npm is on version 5.7.0 then, as a non-root user, with sudo prefix:

sudo npm --help

You 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.

This was not occurring on my system before the most recent update and using 5.6.0 resolves the issue entirely.

Supporting Information:

• npm -v prints: 5.7.0
• node -v prints: 9.5.0
• npm config get registry prints: https://registry.npmjs.org/
• Windows, OS X/macOS, or Linux?: Arch Linux (latest base)
• Network issues:
  • Geographic location where npm was run: UK
  • [ ] I use a proxy to connect to the npm registry.
  • [ ] I use a proxy to connect to the web.
  • [ ] I use a proxy when downloading Git repos.
  • [ ] I access the npm registry via a VPN
  • [ ] I don't use a proxy, but have limited or unreliable internet access.
• Container:
  • [ ] I develop using Vagrant on Windows.
  • [ ] I develop using Vagrant on OS X or Linux.
  • [ ] I develop / deploy using Docker.
  • [ ] I deploy to a PaaS (Triton, Heroku).

[welwood08]

I experienced similar chaos after updating to 5.7.0 in a FreeBSD jail, I noticed recursive ownership of at least /usr/local/etc had been given to the current user:group during the update (npm update -g). Thankfully I could rollback to a snapshot of my filesystem from before the update and 5.6.0 works fine again.

As a precaution against potentially catastrophic effects, I hope 5.7.0 will be taken down while a fix is implemented.

[juggy]

This destroyed 3 production server after a single deploy!

[JSteunou]

Same in a docker as root, some command like npm config set registry complained about EACCESS error on /root dir oO error code return is 7

All worked fine with 5.6 :(

[redboltz]

I experienced similar issue. I'm using AWS ec2 (Amazon Linux AMI 2017.09.1 (HVM), SSD Volume Type - ami-f2d3638a). It's clean environment. (Nothing installed.)

After npm v5.7.0 installed, /usr/bin's execution files ownership is updated to ec2-user:ec2-user from root:root. After the update, I cannot do sudo, so I need to re-create EC2 instance.

Here is the commands that reproduces the situation:

on ~ec2-user directory,

ls -l /usr/bin
# you can see correct ownership

sudo su
curl --silent --location https://rpm.nodesource.com/setup_6.x | bash -
exit

sudo yum update
sudo yum install git
sudo yum install nodejs
git clone https://github.com/isaacs/npm.git
cd npm
git checkout v5.7.0
make
sudo make install

ls -l /usr/bin
# you can see broken ownership

[pakastin]

Why are you using a pre-release version in production @juggy? Just asking...

[linaori]

Tag doesn't look like pre-release until you actually click on the releases and check the tag. If it's a pre-release tag, I suggest to not format the tag in a way it looks like it could not be a pre-release tag.

[rpadovani]

I suggest to do no publish pre-release version announcement on the official blog: http://blog.npmjs.org/post/171139955345/v570

[stefanotorresi]

I suggest to do no publish pre-release version announcement on the official blog: http://blog.npmjs.org/post/171139955345/v570

...which doesn't mention it's a pre-release in any way, shape or form.

[AlexWayfer]

Pre-releases is alpha, beta, rc, pre, etc. …

5.7.0 looks like minor stable release.

[kciredor]

lol

[pakastin]

Sorry people, wasn’t meant to be rude 🙄

[odykyi]

npm 5.7.0 on Mac not worked

[petetnt]

@towc welp, missed that 🆗

[linuxenko]

haha )) can someone prove that this update does destroy production servers ?

[Crest]

Oh yes

[vinicius73]

Doc link https://docs.npmjs.com/getting-started/fixing-npm-permissions

[linaori]

Mind staying on topic, rather than enforcing your opinion on us for an unrelated subject? Thanks!

[Shredder121]

Interesting 🤔

https://github.com/npm/npm/blob/d3095ff20b8ea01e7fbf93a4a697a04fea77d8e6/lib/utils/correct-mkdir.js#L31

[icedream]

I think it would be preferable to only explicitly set permissions on folders that actually will be created by npm instead of just tinkering with the existing folders, especially when that code is accessing critical folders as the root user (through sudo). In the worst case, this renders systems unbootable and/or unusable.

On another note, it is indeed confusing to just use v5.7.0 as a pre-release version name despite the pre-release marker on GitHub. Or is the routine to mark upcoming releases as pre-releases and then just switching them over to stable release as-is?

[ansuz]

🍿

[tobozo]

consider reading this

[christianjgreen]

Playing a dangerous game by doing a minor stable release that's actually a pre.

[ghost]

Things like this are like a :eggplant: in the face of npm and node. And I love it.

[trodrigues]

For the people asking "why is 5.7.0 a prerelease released as stable", it's not:

{ latest: '5.6.0',
     next: '5.7.0'

It's tagged as next, so if you got it you either explicitly installed that version knowing it's marked as next, or you installed @next.

Release channels exist for a reason. If you're running "next" on production environments you're asking for trouble.

[elliotd123]

If what he's saying is correct, the pre-release appears to be pushed to the Arch main repositories, so if you're on Arch, beware! I've uninstalled npm and nodejs from my Arch box for the moment just to prevent any extra fun until this bug is fixed.

EDIT: it appears I misread his steps to recreate. Updating npm from npm is what installed the 5.7.0 version. Still bad, but not related to Arch's repositories.

[nickserv]

[ghost]

@trodrigues might be still worth writing about this more explicitly on the blog post. Nobody coming to the site would know from reading it that it's a pre-release at the time.

Edit: for clarity, I'm referring to this: http://blog.npmjs.org/post/171139955345/v570

[cloudlena]

I ran npm update -g this morning and my local npm 5.6.0 was upgraded to 5.7.0 so in some way, it must have gone beyond a pre-release.

[ghost]

Generally in projects that follow semver I expect pre-release packages to have some string suffixed to the version number such as 5.7.0-next.

This is only listed as a MAY in the spec but it does allow you to immediately tell if a release is considered stable or not just from the version number.

[catwell]

If what he's saying is correct, the pre-release appears to be pushed to the Arch main repositories, so if you're on Arch, beware!

I don't know where you see that, but it's not the case.

[elliotd123]

@catwell from OP's steps to recreate. OP may not have included all the details.

Indeed, it looks like OP must have some other config. I don't see it in any of Arch's main repositories.

[MrElendig]

@elliotd123 Sure it was pushed to the arch repos? https://git.archlinux.org/svntogit/community.git/log/trunk?h=packages/npm seems to indicate otherwise.

[petetnt]

@mastertinner reported the update installs newest than latest in https://github.com/npm/npm/issues/19888

npm update and npm outdated for some reason manage to report newer versions than latest which they should not.

Tagging as pre-release (and as @next on the registry) is semver compliant so its a non-issue.

[ghost]

Maybe it would be good to pull back the release for now? If such a thing is possible.

[thomwiggers]

See also https://github.com/npm/npm/issues/9359: npm has been changing permissions in critical directories for a long time. This issue was wrongly autoclosed.

[catwell]

OK, @petetnt actually meant #19888, so ending up having 5.7.0 is not Arch-specific, it is related to using npm to update npm...

[anthraxx]

@lutzhorn because of their weird auto closing policy, a security contact confirmed the problem with that but nobody though it would be a good idea to open the bugreport :man_shrugging:

[ghost]

@anthraxx Didn't notice this. Even worse :(

[Crunkle]

@elliotd123 all details to reproduce the bug were included and confirmed by other users experiencing the same issue on non-Arch platforms. This isn't isolated to a specific configuration file or distribution as far as I'm aware.

Just mopping up my tears whilst reinstalling Arch for the 3rd time this month.

[ghost]

laughs in Windows

Yikes.

[ghost]

laughs in Windows

Yikes.

[HacKanCuBa]

Seriously, undo the tag! And use semver to mark pre-release, not just GH release... And sysadmins: verify prior upgrading blindly, specially to a new release, either major or minor.

[envygeeks]

Today is gonna be a fun day. I won't have had this many calls since Spectre/Meltdown. Thanks! 🙄

[aitbw]

Just wondering, @Crunkle: Why did you install both Node and NPM from the Arch repos? AFAIK, installing programming languages/package managers binaries from a distro's repos is a really bad idea, especially when it comes to permissions.

[dos1]

@aitbw Uhmm, no.

[eli-schwartz]

If what he's saying is correct, the pre-release appears to be pushed to the Arch main repositories, so if you're on Arch, beware! I've uninstalled npm and nodejs from my Arch box for the moment just to prevent any extra fun until this bug is fixed.

I challenge your bizarre assumption: https://www.archlinux.org/packages/community/any/npm/

This is not something difficult to check, please don't spread FUD. As the OP said:

I am personally using Arch Linux with the latest npm package, installed as the root user via:

pacman -Sy npm nodejs npm install -g npm npm install -g semver

[ghost]

@aitbw Installing programming language specific package managers is a really bad idea no matter how you install them.

[konistehrad]

For what it's worth, running npm update -g npm installed the broken 5.7.0 pre-release, while npm install -g npm downgraded to the working 5.6.0. Unsure if this is intended behavior:

[aitbw]

@aitbw Uhmm, no.

Could you elaborate further on that, @dos1?

@aitbw Installing programming language specific package managers is a really bad idea no matter how you install them.

How so, @Tsutsukakushi?

[tobozo]

NPM socks