​Show-stopping bug appears in npm Node.js package manager

A new release of the JavaScript and Node.js package manager, npm, fatally changes file permissions. While that's been fixed, the entire messy process revealed more fundamental problems.

The rising tension between IoT and ERP systems

The Internet of Things is the new frontier. However, generations of ERP systems were not designed to handle global networks of sensors and devices.

Read More

Are you a developer who uses npm as the package manager for your JavaScript or Node.js code? If so, do not -- I repeat do not -- upgrade to npm 5.7.0. Nothing good can come of it. As one user reported, "This destroyed 3 production servers after a single deploy!"

So, what happened here? According to the npm GitHub bug report, "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."

In other words, this installation changes core Linux file and directories ownership and permissions so they will will crash the system. Many others are reporting that they're seeing the same problem on Linux on a variety of platforms, macOS, and FreeBSD.

This had led to a lot of heated conversation about the release. Or, was it a release?

Others state that if you look at the actual code, you'll find that the version out now is a pre-release and shouldn't be installed. They are correct. The code does indicate that 5.7.0 was not ready for release. Still, others point out that the npm blog announcing 5.7.0 certainly reads like an official release announcement.

This has led to a lot of finger pointing. In the meantime, 5.7.1 has been released, with a fix for this mission-critical problem.

While this problem has been fixed, it revealed more fundamental troubles.

First, npm is a major part of the Node.js and JavaScript. These, in turn, run many of today's websites. For all of npm's importance, the npm project has only two -- count them, two -- developers. This makes the project far too vulnerable to simple errors or even as something as commonplace as both programmers sleeping when something goes wrong.

This isn't the first time npm has shown just how fragile it is. Two years ago, npm broke catastrophically when a developer jerked out a 7-line npm program called "left-pad", which thousands of Node.js programs needed to function. Essential programs should not be run on a shoestring with only two core developers.

The installation routine itself is asking for trouble. As one developer on Ycomb observed, the "npm binary is run as sudo and then uses the UID and GID of the invoking user when chowning the directory. I feel like screaming, who thought this was a good idea? If I invoke something as sudo, why does anyone think it should try to detect that and do anything about it? I want to run as the user sudo has set, not my own user, OBVIOUSLY."

Running any command, especially one that makes serious changes to the operating system as the root or administrative user, is always dangerous. Making matters even more annoying, there's no need to be the root user to install npm. There have long been multiple ways to install npm as an ordinary user. Do any of these and you can avoid blowing up your production system.

Oh, which reminds me. What are you doing running any brand new code on a production system? This is sysadmin 101. You don't run a fresh release of any program on a working system. Capiche?

While the code problem was critical, what this entire episode really revealed is an open-source community that needs to do a better job of managing, delivering, and using its program. In all three phases, its developers, managers, and users failed. This can't carry on if npm is to continue to be an important program.

Related Stories: