Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Bug Operating Systems Linux

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

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.
This discussion has been archived. No new comments can be posted.

Botched npm Update Crashes Linux Systems, Forces Users to Reinstall

Comments Filter:
  • LOL (Score:5, Funny)

    by ArchieBunker ( 132337 ) on Thursday February 22, 2018 @04:53PM (#56171213) Homepage

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

    • Re: (Score:3, Funny)

      I'm guessing 'ownership' is too racist, capitalist, and phalocentric to be a valid concept in filesystem design form much longer.
    • Re:LOL (Score:4, Interesting)

      by shaitand ( 626655 ) on Thursday February 22, 2018 @05:47PM (#56171647) Journal
      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.
    • by AmiMoJo ( 196126 )

      How come a script can adjust permissions on critical system directories?

      It's always seemed a bit odd that Linux runs stuff like this as the superuser who can basically do anything. No granularity, no account just for installing JavaScript (!) packages... It's like Windows XP again.

      • Re: LOL (Score:2, Insightful)

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

        • 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 (Score:5, Informative)

    by Camel Pilot ( 78781 ) on Thursday February 22, 2018 @04:54PM (#56171217) Homepage Journal

    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 (Score:5, Informative)

      by RightwingNutjob ( 1302813 ) on Thursday February 22, 2018 @05:02PM (#56171267)
      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.
      • "automatically and implicitly trusting package maintainers to do the right thing is awful security policy and awful from a reliability standpoint."

        And this is why this, 2018, is the year of Linux as THE desktop.


      • In fairness... if it isn't for home use and you are using javascript you kind of had it coming.
      • by Malc ( 1751 )

        It's a breathtakingly poor development process that led to this collossal fuck-up, Do you really think they haven't tested at all though, or they just don't work in an enviroment that mimics their users, or don't test the same package that goes to users? How does a development change get to users with npm?

        I've worked with QA teams that test different build artefacts than the ones that go to customers because they don't want to deal with installers and things like that in their automated environments. And

    • I'll bet there will be a script to fix this before dinner.
    • Re:Rescue mode (Score:5, Interesting)

      by Dracos ( 107777 ) on Thursday February 22, 2018 @05:37PM (#56171559)

      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.

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

        So Javascript developers then.

    • No,
      there are varied permissions in my etc folder
      not everything is owned by root:root
      do you know off the top of your head the permissions of all files and folders in /etc,
      good on you.

    • by jrumney ( 197329 )
      If it has chmod -R a whole hierarchy to its own preferred universal permission (formerly 777 which noone noticed, but one of the devs read a blog about security and changed it to 600 for this release), then putting back the original permissions for all the thousands of files and directories is a major task. You basically need to install another system as a reference to copy the permissions from, so you might as well reinstall everything.
    • Yeah it's not like the bumblebee sudo rm -rf /usr bug. Now THERE was an update that needed a reinstall!

      https://github.com/MrMEEE/bumb... [github.com]
    • If it is a file permission issue... boot from install disk into rescue mode... chmod and reboot. I don't get it.

      Chmod to what? Do you remember what the user and group permissions on every single file on your system were?

      Seriously, it's easier to reinstall.

  • by jawtheshark ( 198669 ) * <slashdot@ja w t h e s h a r k . com> on Thursday February 22, 2018 @04:56PM (#56171235) Homepage Journal
    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.
    • by Gojira Shipi-Taro ( 465802 ) on Thursday February 22, 2018 @05:03PM (#56171279) Homepage

      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.

      • Otherwise you're at thw mercy of the platform team

        You do realise this is why Linux "distributions" exist in the first place right? Seriously the dependency for everything in the system should be maintained by one group and one group only. Otherwise you end up with some package manager making a change to a system incompatible with another package manager and the entire mess gets royally screwed.

        The only time I've ever been forced to nuke the root partition and start from scratch in Linux was due to complete loss of plot by a package manager.

      • I'd like to see all non-OS package managers just run as a user (not root). They can throw all the crap they want wherever they like in their own directories, but for all the root-owned stuff, use an OS package like everyone else.

        Whilst I'm being a bit angry about this, I think it would actually lead to a far better (and safer) solution than we have today. The likes of NPM can run as the 'npm' user and can do nightly updates if they want, and I, the sysadmin will know that it's 'safe' in so much as it'll onl

    • by BlueLightning ( 442320 ) on Thursday February 22, 2018 @05:05PM (#56171287) Homepage Journal

      I'd recommend watching this talk:

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

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

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

      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.

      • by Junta ( 36770 )

        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 o

    • by PPH ( 736903 ) on Thursday February 22, 2018 @05:09PM (#56171329)


      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.

      • Indeed. Install as Root is the killer of both *nix and Windows. What is the point of having a permission system if every program we run needs to have root on install.

        IOS taught us the right way. That we should be able to install third party software and not give it complete control of our systems. Well, almost...

      • The macOS package manager Homebrew (http://brew.sh [brew.sh]) has some flaws but one of my favorite features is that it operates entirely within its own tree at /usr/local/Homebrew. Installing the package manager in the first place requires root to gain permission to write in /usr/local but after that, all operations are done at user permission levels.
    • by Dracos ( 107777 )

      Some npm packages are as little as 7 lines of code... they have more metadata than content. Do you really want all that (350,000 packages as of January 2017) cluttering up your OS-level package manager?

      • by Junta ( 36770 )

        That's a problem in and of itself. There's no sane reason for such a small function to be a library all it's own, rather than coordinated in a larger, cohesive project.

        • by Dracos ( 107777 )

          JS kiddies take DRY to previously unfathomable heights of zealotry, and can't abide including code they don't need. Their eternal quest for perfect code mass optimization explains a lot of the problems with how JS has evolved.

    • by Junta ( 36770 )

      Note that I agree with you, however people going after copr or ppa sorts of repositories have equal amounts of ability to screw over a system. The general impatience that leads to using the free0for-all package manager associated with a language will also lead to a free-for-all of yum/apt repositories.

      Of course, the quality of rollback solutions is higher with the distro manage, hence my agreeing with you, but the problem is still complex beyond just using the crappier package management.

    • by Malc ( 1751 )

      This might work if you only support one platform. But now you need to do something for macOS (ports, homebrew, appstore?) and for Windows (msi, appstore, something else?) All very different, so I'm pretty sure it's less effort and cost to have a common solution specific to your language. But perhaps there is a place for a language neutral cross-platform package manager, but that would take a lot of effort to overcome the momentum behind things like Perl's CPAN or Python's PiP.

  • Ugh (Score:5, Insightful)

    by i_ate_god ( 899684 ) on Thursday February 22, 2018 @05:53PM (#56171715)

    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.

    • by v1 ( 525388 )

      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.

      Maybe those "developers" and "engineers" need to learn how to fix their systems with the super-advanced CHOWN command, instead of reinstalling??

    • This reminds me of the Jenkins (centos) RPM. It used to do all the package extract and then did a 'chown -R /var/lib/jenkins' - innocuous enough, given everything in there should be owned by Jenkins anyway. The trouble was, some of us had gigabytes of files and jobs in there (in my case, it got so big we had to put it on an NFS share), so the chown would literally take hours/days. It took 2 years to get the issue fixed: https://issues.jenkins-ci.org/... [jenkins-ci.org]

      OS packaging is actually pretty hard unless you know ev

  • 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 ign

    • My first command when doing admin stuff is usually "sudo -i" to get me a root user shell. Repeatedly typing "sudo" is a waste of 5 keystrokes.

  • mtree(8) (Score:4, Interesting)

    by MavEtJu ( 241979 ) <[slashdot] [at] [mavetju.org]> on Thursday February 22, 2018 @08:52PM (#56173067) Homepage

              mtree -- map a directory hierarchy

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

              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.

    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
  • by jrumney ( 197329 ) on Friday February 23, 2018 @12:10AM (#56173997)

    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.

    • This is why I always reject anything that has requirements that I install the latest version of everything

      Please send me through your IP address. I look forward to having another internet connected machine at my disposal.

      • by jrumney ( 197329 )
        You are conflating the latest version, which is generally unstable and full of potential zero days, with security patches, which distributions do a good job of backporting to the stable versions they are shipping when the ADHD developers of the upstream are too lazy to maintain anything other than git HEAD.
  • This explains a lot. A couple weeks ago I was complaining about having to build a Javascript app written using Babel and NodeJS. The build was designed to automatically check for and download the latest version of all packages with NPM before building. After the inevitable swath of updates, things were so broken beyond repair that even re-installing all the packages didn't fix the build system. The only way I was able to get anything to build again was by resetting my VM image and reinstalling from scra

  • The first tweet in TFA really takes the cake:

    "“if I run sudo npm --help my filesystem [changes] ownership of directories such as /etc, /usr, /boot”"

    You don't even need to install or make a change to the system. Simply sudoing npm is enough to trigger the bug. Ironically those people who are ballsy enough to run everything as root are unaffected since this seems to be some iteration with sudo only.

    Epic fail. Wait are we still doing Epic fail or are we just saying "Sad!" ?

    • by jrumney ( 197329 )
      Any tips for safely checking the version of npm installed? If npm --help screws things up, I expect npm --version probably isn't a good idea either. I guess something like strings $(which npm) | grep 5\.7 would be the best way to check if I'm compromised?
  • Drop npm. Use yarn. It has a lock file, it's quick, doesn't DoS the DNS until it decides to timeout, it doesn't take half an hour to install the packages in Gitlab CI, and it feels professional... Yarn is just lovely.

Things equal to nothing else are equal to each other.