Hacker News Reader

Hacker News

Comment by belltaco | Hacker News Reader

Parent Full thread

belltaco

Wonder if an author will rename themself sudo rm -rf / with the proper escape codes.

View on HN

You my friend, are an evil, sadistic meglomaniac. I love it. Remind me not to make you mad.

Bobby wants his tables back!

Legend has it that all data related to little Bobby Tables has been lost.

`rm -rf ~` is disastrous enough on macOS with a bonus of not having to authentiacate sudo.

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.

> Time Machine helped me quite a lot but unfortunately with a nasty surprise that it doesn't backup dot files.

Wow, that's good to know!

PS: it turns out you can restore dot files from the Time Machine backups but it's not enabled by default:

https://apple.stackexchange.com/questions/141321/how-to-rest...

When I learned about this command 10 years ago I tried it on a Debian system that I had no use of anymore.

There's a big warning before it lets you execute the command.

That's true only of distributions that alias rm with rm -i.

Now, almost 20 years ago only RedHat did it. And it felt wrong to me :-/

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.

[1]: https://en.wikipedia.org/wiki/Rm_%28Unix%29#Protection_of_th...

worth noting that it can be trivially workarounded by adding an asterisk at the end: `rm -rf /*` still works.

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.

That version will helpfully leave behind any .files lingering in /

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.

I want to try that dd command. For fun. Just to see what happens on OpenBSD.

No lasting effects are there? Besides a crash, afterwards I shouldn't have any memory issues, right?

I tried this in a FreeBSD VM and it booted fine afterwards. OpenBSD wouldn't let me do it at all for some reason.

Obviously no warranty on bare metal/systems that are actually used for anything.

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.

Curious to know how you recover from that? How do you what permissions to assign back to files and directories?

Curious to know what circumstances led up to someone doing that and if they were charged for other violations.

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.

https://askubuntu.com/questions/308939/how-to-reset-default-...

https://askubuntu.com/questions/508359/restore-default-syste...

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.

A modern shell should prevent you from directly executing pasted code.

Reply on news.ycombinator.com