Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by msmash on from the beware dept.

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.

15 of 256 comments (clear)

  1. LOL by ArchieBunker · · Score: 5, Funny

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

    --
    Only the State obtains its revenue by coercion. - Murray Rothbard
    1. Re:LOL by RightwingNutjob · · Score: 3, Funny

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

    2. Re:LOL by Anonymous Coward · · Score: 5, Funny

      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.

    3. Re:LOL by shaitand · · Score: 3, Interesting

      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.

  2. Rescue mode by Camel+Pilot · · Score: 4, Informative

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

    1. Re:Rescue mode by RightwingNutjob · · Score: 4, Informative

      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.

    2. Re: Rescue mode by Computershack · · Score: 4, Insightful

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

      --
      I only please one person per day. Today is not your day. Tomorrow isn't looking good either. - Scott Adams
    3. Re:Rescue mode by Dracos · · Score: 5, Interesting

      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.

  3. I remain of the opinion... by jawtheshark · · Score: 5, Insightful

    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.

    --
    Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
    1. Re: I remain of the opinion... by Gojira+Shipi-Taro · · Score: 3, Interesting

      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.

      --
      "Oh my God. This is terrible. This is the end of my Presidency. I'm fucked."; ~ Donald J. Trump
    2. Re:I remain of the opinion... by BlueLightning · · Score: 5, Informative

      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.

    3. Re:I remain of the opinion... by PPH · · Score: 4, Insightful

      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.

      --
      Have gnu, will travel.
  4. Ugh by i_ate_god · · Score: 5, Insightful

    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.

    --
    I'm god, but it's a bit of a drag really...
  5. mtree(8) by MavEtJu · · Score: 3, Interesting

    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.

    --
    bash$ :(){ :|:&};:
  6. Always requiring the latest version of everything by jrumney · · Score: 3, Informative

    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.