How do people know the result of running this command without running a VM? Is it possible to run OS X in a VM these days?
The command's intention is so obvious I wonder why there is no warning from the os, the shell program or the terminal for such, easily blacklist-able commands. Or is there?
I've learned that personally one night fighting messed up rebase conflicts and for still unknown reason I copied and pasted a path for `rm` and ended up issuing `rm -rf ~ /repo-path /unneeeded-dir` - it took me a couple of seconds to realize that this command takes unexpected long time to execute and then my eye caught a view of Finder window with shrinking list of folders in home directory :) Time Machine helped me quite a lot but unfortunately with a nasty surprise that it doesn't backup dot files :-/ Lessons learned.
Modern versions of rm require you to pass --no-preserve-root. According to Wikipedia [1] this has been the default (in upstream) since 2006. Of course it took distros some time to actually update to the GNU utils 6.4 (especially long-term support systems like CentOS) but it's been a decade since the change should've been implemented everywhere.
Isn't that only a GNU and FreeBSD thing? I think other Unixes will still let you rm -rf /.
On FreeBSD you can do
sudo dd if=/dev/random of=/dev/mem
and it will do exactly that, write random crap into your memory without any sort of safeguard, causing a spectacular crash and a console that looks like it's having a seizure. Linux won't let you do that unless it's been compiled with a flag to enable full access to /dev/mem and /dev/kmem.
Fair enough, but on the other hand there's nothing preventing you from just putting --no-preserve-root in the command either. I see the feature as something to prevent accidents, not as a way to secure the rm command.
Maybe run `sudo chmod -R 000 /` instead. Can't get charged with destroying any data, but it's a huge pain to get a system working again from that. Only done it twice; hope never to do so again.
Depending on how you define "fix," the common way (if the machine has already been rebooted and you're locked out of the session) is to boot via a live distro, mount the filesystem, and change permissions to get a usable system back. There are various other methods depending on the machine state and requirements, too, so it's definitely recoverable from a working machine standpoint. Changing permissions back to what they used to be is a rabbit hole that varies depending on your distro, machine-specific requirements, and any special permissions setup by you and your admins.
It's a pain-and-a-half. I'm not sure any system ever recovers fully, but you basically run chmod -R's on most of the important directories and then fix the many services that will surely fail once you can get a shell.
More specifically, I used a bunch of these links until I could get a shell, then manually-fixed the rest.
Can confirm. I kept getting permission errors on something I was testing, and in desperation ran `chmod -R 777` thinking I was in my project dir. I was actually at root. After a bunch attempts to recover, I ended up saving the data I cared about and doing a fresh install. 0/10 would not recommend.