5 ms·

> 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 ab

by biturd 14y ago

> 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 14y ago
everything in my /usr/local is owned by my user. isn't this typical in the case of a dev machine?
- wtallis 14y ago
  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.
  - dagw 14y ago
    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.
  - uxp 14y ago
    /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.
cma 14y ago
Typically anything owned by your user is much more important to you than anything owned by root (from the perspective of it getting deleted).
steve-howard 14y ago
rm -rfi results in a lot of noise, and it becomes a habit to simply dismiss the warnings without reading them.

by biturd 14y ago

mikebannister 14y ago

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

wtallis 14y ago
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.
- dagw 14y ago
  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.
- uxp 14y ago
  /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.

cma 14y ago

Typically anything owned by your user is much more important to you than anything owned by root (from the perspective of it getting deleted).

steve-howard 14y ago

rm -rfi results in a lot of noise, and it becomes a habit to simply dismiss the warnings without reading them.