
Running "n stable" removed bin, lib, share, include directories from /usr/local - almost
https://github.com/visionmedia/n/issues/86
======
benatkin
He merged a pull request from someone he probably didn't know (new to node.js,
different country). Without looking at the rest of the file it looks OK to me.
That's probably what happened - he didn't get all of the program's relevant
structure in his mind when he read the code.

<https://github.com/visionmedia/n/pull/85/files#r1781158>

~~~
zobzu
Which is slightly scary security wise. Over the large number of libs,
programs, etc people often pull half-blind if the code looks "mostly ok and
does what it says"

Except it can do also a lot of other bad things, and its too much to review.
So in the end you trust the tree owner, and he blindly trust a zillion people.

I actually have zero good solution to this, but it'll be interesting when it
is used for a large attack.

~~~
biturd
> I actually have zero good solution to this, but it'll > be interesting when
> it is used for a large attack.

I don't know what this software is or anything about it aside from an
estimating that it appears from comments here and on GH that it's serious as
it deletes highly important directories and is possibly a widely used software
package.

Whenever I install from source I run the installer as non root. It will error
on higher than my user privilege deletes telling me I need to be root. In this
case I believe I would have seen the attempt to remove important directories
as an error alert.

If I have to be root, running as non root first has helped me as a purely
investigative method to installations.

What if everyone adopted an 'rm -rfi' type command for any deletes. Then you
are asked: "You are about to remove $dir are you sure you are okay with this?
Y/N?

In this case, what I don't get is how it's now been three days and there
hasn't been a rollback, pulling of the software, patch, notice, billboard,
radio announcement, Emergency Broadcast Syatem alert, or otherwise some way to
halt this problem dead in it's tracks right this very second.

It's almost like: README This software is 'use at your own risk', etc., etc.,
etc., see Hacker News for any potentially dangerous side-effects caused by
installing this software.

~~~
mikebannister
everything in my /usr/local is owned by my user. isn't this typical in the
case of a dev machine?

~~~
wtallis
If it's going to be owned by your non-root account, shouldn't it be installed
to ~/? It seems like a bad idea for a non-root user to have control over
binaries that are in root's $PATH.

~~~
uxp
/usr/local on a normal, stock OS X install is completely unused. Homebrew's
installer commandeers it by `chown`ing it to the current user and makes it
group writable, as to cut down on the sudo noise. I think issues like this,
and the fact that nearly all package managers, including aptitude, yum and
ports require sudo should be catalysts for requiring sudo for updating and
installation of packages. It's that whole security vs. convenience tradeoff
again.

I've actually run into a similar issue with another installer via a Rakefile
that lacked uninstalling capabilities and a confusing method of determining
the $PREFIX which resulted in me shredding my /usr/local/bin directory for a
couple seconds before my ^C spamming stopped the process.

------
almost
Looks like the mods changed the title I gave. Just for those that don't know,
"n" is a version manager for Node.JS that some use to handle multiple copies
of Node.JS on their system.

~~~
nym
Your original title was slightly linkbaity. I approve of the mod's change for
clarity.

~~~
almost
They were probably right to do it. But it would have been useful to keep the
reference to Node.JS in there as not everyone knows what "n" is.

~~~
ars
I read it as:

"Running and stable with no bin, lib, share, include directories in
/usr/local".

Which didn't seem all that exciting to me, so I clicked just to see what all
the excitement was with not having a /usr/local.

PS. "n" is a terrible name for a program - it's impossible to google.

------
ben0x539
As a non-Node.js user, I'm more bewildered by how easily github issues turn
into reddit threads.

~~~
almost
It only happens occasionally on bugs issues that get a lot of attention (by
being posted to HN for example, sorry about that). Usually GitHub issues
threads are sensible and helpful places.

~~~
ben0x539
That's what so scary to me. There's all that productive discussion that is
only a step over some noteworthiness threshold away from being completely
ruined. I wouldn't think of blaming HN or even reddit submitters for that,
though.

------
cmwelsh
I used to use n before I found out about nvm[1]. I used to have issues
installing Node.js packages with n, but so far nvm just works.

The best advantage of nvm is that I can easily install global packages without
being the root user, because it installs your Node.js files in a per-user
~/nvm/ folder (this is customizable to whatever folder you choose).

[1] <https://github.com/creationix/nvm>

~~~
dfc
_"The best advantage of nvm is that I can easily install global packages
without being the root user"_

One of us is very confused (it easily could be me). I do not understand this
statement at all. How is something global if its in a user directory?

~~~
cmwelsh
When you install a package using npm with the flag -g, it means that the
package is global, i.e. available from any current working directory. The
default is to only search the current directory hierarchy for a folder called
"node_modules". That way every project that you work on can have its own
versions of every library, instead of sharing them for the entire system. You
can learn more about "global" vs "local" packages by reading the npm manual.

------
paulrademacher
<https://github.com/visionmedia/n/pull/85/files#r1781158>

    
    
      |  for d in bin lib share include; do
      |    rm -rf $N_PREFIX/$d
    

LGTM!

------
SCdF
Somewhat off-topic, but allowing people to post inline images-- especially
animated ones, is such an awful idea.

------
tjholowaychuk
my bad, sorry about the limbo-merge guys, I'll read PRs closer and/or ignore
them since I don't have time

------
rat87
Reminds me of [https://github.com/MrMEEE/bumblebee-Old-and-
abbandoned/issue...](https://github.com/MrMEEE/bumblebee-Old-and-
abbandoned/issues/123) (install script does rm -rf /usr for ubuntu) although I
guess deleting /usr/local isn't nearly as bad.

~~~
1SaltwaterC
Depends on platform. It is under FreeBSD. It wipes the entire userland that
isn't part of the base system. That means every piece of software installed
from the ports collection.

~~~
lmm
Yeah, but honestly that's FreeBSD's fault for installing system-managed
software in a poor location for such.

(speaking as a FreeBSD user myself)

------
protomyth
Makes me wish we had a transactional file system and the ability to force
certain deletes to verify even if run as root with the -rf flags so we could
roll back this type of thing.

~~~
lmm
My setup is pretty simple and could recover from this with few problems: I use
ZFS and have zfSnap configured to take a snapshot every hour, saved for five
days. So I'd lose potentially the last hour's worth of changes to /usr/local,
but that's unlikely to be big.

~~~
mcosta
bsd? linux? solaris?

~~~
lmm
FreeBSD; I didn't trust any of the ZFS implementations for linux (I'm not sure
there is one that works for your root filesystem yet?) and Solaris didn't find
all of my hard drives.

If you're thinking of switching there really isn't much difference between
FreeBSD and Linux (at least if you're talking about a traditional Linux like
Slackware); most of the admin commands work like Linux did up until 5 years
ago, and obviously the UI is just KDE or whatever you like.

------
Evbn
Wow, just today I commented on the Anvil post about how to delete your system
using this exact bug.

