Hacker News new | ask | show | jobs
by jmnicolas 2307 days ago
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.

1 comments

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

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.

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 /