Re:Running "n stable" removed bin, lib, share, include direc...
by cma on Sunday October 07, 2012 @11:14PM
(#4625363)
Typically anything owned by your user is much more important to you than anything owned by root (from the perspective of it getting deleted).
Re:Running "n stable" removed bin, lib, share, include direc...
by steve-howard on Monday October 08, 2012 @12:23AM
(#4625492)
rm -rfi results in a lot of noise, and it becomes a habit to simply dismiss the warnings without reading them.
Re:Running "n stable" removed bin, lib, share, include direc...
by mikebannister on Sunday October 07, 2012 @09:41PM
(#4625147)
everything in my /usr/local is owned by my user. isn't this typical in the case of a dev machine?
Re:Running "n stable" removed bin, lib, share, include direc...
by wtallis on Monday October 08, 2012 @02:16AM
(#4625711)
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.
Re:Running "n stable" removed bin, lib, share, include direc...
by uxp on Monday October 08, 2012 @09:45AM
(#4626781)
/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.
Re:Running "n stable" removed bin, lib, share, include direc...
by dagw on Monday October 08, 2012 @06:09AM
(#4626178)
On a server or an environment where you don't trust your users, absolutely. On your own private dev machine that's only used by you, doing things the 'wrong' way is often perfectly acceptable and makes life easier.
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.