Botched npm Update Crashes Linux Systems, Forces Users to Reinstall (bleepingcomputer.com)

Catalin Cimpanu, reporting for BleepingComputer: A bug in npm (Node Package Manager), the most widely used JavaScript package manager, will change ownership of crucial Linux system folders, such as /etc, /usr, /boot. Changing ownership of these files either crashes the system, various local apps, or prevents the system from booting, according to reports from users who installed npm v5.7.0. -- the buggy npm update. Users who installed this update -- mostly developers and software engineers -- will likely have to reinstall their system from scratch or restore from a previous system image.

Comments

LOL

[ArchieBunker]

A shitscript package manager that does a chmod of /etc and /boot? This thing had to have been written by that Poettering asshole.

Re:LOL

[RightwingNutjob]

I'm guessing 'ownership' is too racist, capitalist, and phalocentric to be a valid concept in filesystem design form much longer.

Re:LOL

[Anonymous Coward]

Do you guys really need to inject your rightwing politics into literally EVERY story????

It's a memorial to the language which attempted to shatter the glass ceiling but was stopped by the patriarchy.

Re:LOL

[shaitand]

The thing sucks so bad. I've had a few things that required npm... everyone pretends it's like apt or yum that grab everything you need if you install from a proper repo... npm has never gotten all the dependencies on a fresh clean host for any project I've installed.

Re: LOL

[Anonymous Coward]

I use npm daily as a non root user. People are just too lazy to take the extra 2 minutes to get it up correctly and instead just throw it to sudo. Run shit as root when there is no reason to and you're gonna have a bad time.

Re: LOL

[Reverend Green]

Your laptop is a pet. Your cloud servers ought to be cattle.

Re: LOL

[nnull]

This isn't unusual. It's stupid but not unusual. I've had 'Professional' software developers tell me this is how it's supposed to be. You'll find a lot enterprise software in a lot of industrial settings functioning this way. Giving root access to people that don't understand anything about the system to deal with faults or errors, etc.

This is now standard industry practice. Stupidity is now standard industry practice.

Rescue mode

[Camel Pilot]

If it is a file permission issue... boot from install disk into rescue mode... chmod and reboot. I don't get it.

Re:Rescue mode

[RightwingNutjob]

Maybe. But the point is it's not acceptable to fuck up users' machines and make them go through all that work to fix it.

More precisely, I don't know exactly what should be readable by all vs readable by certain groups vs readable by root only in /usr and especially in /etc. I could very well leave my machine's private keys readable by all by mistake. That's a lot of work to track down. So I'd need to reinstall to ensure that it's all correct and I'm not leaving any holes.

I say again: It's not acceptable to make your users go through that work. And I also say again: automatically and implicitly trusting package maintainers to do the right thing is awful security policy and awful from a reliability standpoint. All updates should be tested before they are deployed. For home users this isn't practical and we have to rely on the distros to do this for us. Trust breaks down severely when fuckups like this go through and it lends credence to people who don't update their software automatically on the grounds mentioned above. This is bad when actual security fixes need to be deployed out, and it's all the more crucial for ALL software maintainers in OSS to make sure their shit works. Trust is the currency of OSS, and unlike dollars, you can't get some more by going to the bank, you have to earn it.

Re:Rescue mode

[Stomper_Stoddard]

I'll bet there will be a script to fix this before dinner.

Re: Rescue mode

[Computershack]

I'm guessing you've never run Windows 10.

Re:Rescue mode

[Dracos]

The people most likely to be using npm, and an apparently untested bleeding-edge version of it that gets pushed out automagically (there's a separate bug that pushed out 5.7.0 prematurely), deserve this rancid dog food. This is incontrovertible proof that the JS community lacks competence and leadership.

Re: Rescue mode

[Jerry]

"Windows recovers from some things well, others... not so much. Same can be said with Linux and OS X"

Don't know about Windows, I haven't run it in 10 years. But, I run KDE Neon on top of Btrfs and there isn't a better FS for Linux than Btrfs. Making snapshots of @ and @home take only seconds and doesn't use any HD space. Rolling back to your last snapshot to recover from anything takes less than 2-3 minutes.

Re: Rescue mode

[slazzy]

Yeah, reinstalling OS X from time machine is so easy it's almost fun.

Re: Rescue mode

[guruevi]

Haha, hahahahaha, haaaahahahahaha.

In Windows you can indeed change boot file permissions and the system won't care a bit because everything ignores or is capable of ignoring it. That is wrong.

Also, recovery is easy for Linux, you can chroot and apt reinstall everything or manually recover permissions. Windows has no package manager much less repair installed applications.

I remain of the opinion...

[jawtheshark]

I remain of the opinion that none of those "language specifically package managers" have no place on Linux systems. They should use the operating systems package managers and tools.

Re: I remain of the opinion...

[Gojira Shipi-Taro]

Good luck with that. Having a packafing system for a language allows consistency across platforms. Otherwise you're at thw mercy of the platform team, or you have to maintain separate packages for platforms woth different release and maintenance cadences.

Re:I remain of the opinion...

[BlueLightning]

I'd recommend watching this talk:

    https://www.youtube.com/watch?...

or if you prefer, the excellent-as-usual LWN summary:

    https://lwn.net/Articles/71231...

I don't like the language-specific package manager situation either, but the way these languages split things up does not lend itself well to the distro packaging model either unfortunately.

Re:I remain of the opinion...

[PPH]

This.

Or nothing other than the system package manager should run as root. Create a top level sub directory and a product specific user/group. And then let it run in it's own file space as its own user. There is very little on a *NIX system that HAS to be owned by root. As long as it's readable and executable by all, that's good enough.

Re:I remain of the opinion...

[Junta]

Eh, not really, except *maybe* the rust situation, but even that has been accommodated (by having the major version of a package embedded in the name of the package).

First, the general answer that 'locks on to versions' is a recipe for security and bug nightmares. In that universe, no longer is it feasible for a foundational library to fix the problems they caused all on their own, becuase the apps statically linked. An openssl tweak means the world has to be rebuilt becuase everyone baked it in instead of relying upon the contract of a major version.

One of the main problems is that developers have no interest in anything that would constrain them, and honoring a contract where they fix things in an API and ABI compatible way is just such an annoyance they won't bother with. By extension, they don't want to ever promise that 2.1.2 will be compatible with 2.1.1. The fix for this has thus far professional linux companies paying people to do the 'boring' work of back-porting fixes to declared stable development bases.

However, there are practical limits to what the enterprise distros can do, so inevitably, there is going to be a body of assets out there with attractive features, but no one backing it. This seems 'fine' to a new developer and they ride the wave. Until that wave crashes, and their app depending on 'foo' causes a problem when foo went to 2.1.2 from 2.1.1 and broke compatibility. This pain is inflicted enough they say "that's it" and put in their requirements "we require *exactly* foo 2.1.1", and they start doing this proactively on all their packages.. Rather than targeting a 'stable' release, they target an arbitrary "it seemed to work at the time version", with no one supporting that particular vintage. They then move on, forgetting entirely about the project that now bores them, and all the security and other bug fixes that happen after 2.1.1 are denied to users of that app. The concept of installing multiple applications in the same namespace becomes impossible, as they all start depending on versions that are mutually incompatible.

Essentially, the ugly mess that is npm, pypi, etc is a symptom of a much bigger problem, a lack of discipline in major projects. The result is either an unusable mess or a dangerously unmaintained stack. Note that this is not a 'young folk' problem, there are plenty of people getting into the market recognnizing the problem and sticking to technology choices that sidestep it. The problem is the people who do try and fail to ride the wave of random software updates are very *loud* about their problems, and their problems simply must be solvable using some technology, not having to adjust or be mindful of the policies of the teams that back the tools they want to use.

Javascript suffers more due to the reluctance of extending the base for utterly common tasks, causing people to invent frameworks and libraries to do things like simple string formatting, which is standard in *every* other language, but not javascript.

Re:Running npm as root

[glitch!]

"Well, it seemed like a good idea at the time. But looking back, I can see it was a bad idea giving guns to monkeys."

Ugh

[i_ate_god]

1. There is no reason to run a language-specific packager as root, whether npm, pip, composer, maven, etc. Either the package manager makes packages available to the user in $HOME, or there exists some kind of virtual environment tool. Use them.
2. Why is NPM chowning anything?
3. Read the thread, the attitudes there are unfortunate to say the least. A new version of NPM is provided when using NPM to upgrade itself without any arguments, and it grabs a "pre-release" version without warning? The version number is 5.7.0, not 5.7.0-beta or 5.7.0-rc1 or whatever. The NPM people violated semver. So there was no obvious way to know this is not an official release.

Re:Ugh

[Junta]

Easy, because there's a large body of content saying "it's ok to do all that stuff, because continuous delivery!".

Some people will say "but that's not what it means" and some of those will have very reasonable implementations and call it that. While they are doing right by themselves and their team, they only make the problem worse because others see 'success' and decide that downloading and random code in production is ok, because this other guy did it and it seemed to work out.

sudo bites again

[tender-matser]

What is not mentioned in the summary is that the bug only shows up when using sudo.

Sudo is a nightmare, both technically and psychologically (strangely, it's seems easier to run 'sudo npm' or 'sudo fuck_me' than running the same commands when logged in as root).

It makes me laugh any time when I try to build some shitty program (inside a vm, of course), and more often than not, it tries to run 'sudo' from the install rule and trash over my system by writing and overwriting files inside /usr and /etc, and ignoring any PREFIX option, despite that convention being almost 40 years old.

I really don't understand the appeal of 'sudo' -- what's the problem with ssh root@localhost with public key authentication?

Re:sudo bites again

[Junta]

It's really ubunutu that popularized sudo as 'the way'.

To be fair, the order of the day prior to that was that people logged in as root to avoid the hassle, sudo is better than that.

To those suggesting 'su is better' or 'ssh root@localhost' is better, any popularized approach would ultimately land in the same land of abuses.

Of course unless you setup sudo :NOPASSWD, that's just stupid and not the way any of those things come by default.

mtree(8)

[MavEtJu]

NAME
          mtree -- map a directory hierarchy

SYNOPSIS
          mtree [-LPUcdeinqruxw] [-f spec] [-f spec] [-K keywords] [-k keywords]
                      [-p path] [-s seed] [-X exclude-list]

DESCRIPTION
          The mtree utility compares the file hierarchy rooted in the current
          directory against a specification read from the standard input. Mes-
          sages are written to the standard output for any files whose character-
          istics do not match the specifications, or which are missing from
          either the file hierarchy or the specification.

Why is root involved?

[Philkeeg]

1. Why is root involved? NPM can be installed and used without requiring root.
2. The issue comes in to play because NPM makes packages available as commands in the system by by PATH. Perhaps they should change this and provide instructions on how to modify PATH to include the bin directory node creates when users install packages globally. At the least, it would have been half-way responsible to craft an installer that does all the setup work for users, requiring root once to run the script that adds PATH vars and install to a specific user.
3. Glad I contained this beast in its own Docker when the need for it arises. I'll expand on this if anyone needs help setting this up and understanding how to containerize things like this (or PHP, fucking python, or any other crap-all-over-the-place RE/PM/etc.) in project tooling or single-use containers. Other tools can be containerized as well; I use docker for Chrome too, which is especially useful when each client gives me a google user for their org and an integrated SSO like Okta which requires a browser plugin.

Always requiring the latest version of everything

[jrumney]

This is why I always reject anything that has requirements that I install the latest version of everything and use a language specific package manager to manage dependencies. Javascript packages seem the worst for the "bleeding edge" requirement, but Java, PHP, Python, Ruby and even Perl have long had issues with requiring the language specific package manager to be used.

If my distro maintainers have not packaged it and tested to the level that the rest of the OS gets tested, then it has no place on my server.