Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

We all know the destructive power of the following command executed as root:

rm -rf /

Related questions:

I fail to see when this particular combination of parameters would be useful, since it destroys the whole system and there are more efficient ways to do that. The rm command could check for these specific parameters, and implement some kind of safeguard - ask for confirmation at the very least, despite the -f parameter.

Why is there no such safeguard in the rm command?

I'm well aware that you must be extra careful when you execute commands as root. With great power (...). However shouldn't this specific case be an exception to that rule?

share|improve this question

closed as not constructive by Nifle, Linker3000, BloodPhilia, DragonLord, 8088 Sep 15 '11 at 14:37

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

8  
I imagine that there is a philosophical bias against it. After all, once you get into the protecting users from themselves business, where should you stop? –  dmckee Sep 15 '11 at 12:43
2  
Like many, i've done this mistake before now (actually, rm -r $variable/ when $variable turned out to be empty). I put the blame on myself for being stupid, not the o/s for not holding my hand, and i wouldn't want it any other way. –  Sirex Sep 15 '11 at 13:37
    
What if rm -rf / is performed after chroot? –  mouviciel Sep 15 '11 at 14:10
    
@Sirex I know that situation rather well. set -u is your friend. If you set variable= though, nothing can save you except defensive programming. –  Daniel Beck Sep 15 '11 at 14:50

3 Answers 3

up vote 16 down vote accepted

It depends on the distribution. The older Linux I'm on right now allows it (I think, didn't test it though :-) ) and states in man rm:

   --no-preserve-root do not treat '/' specially (the default)

   --preserve-root
          fail to operate recursively on '/'

On many recent distributions, you need to explicitly add --no-preserve-root to disable the safeguard. Otherwise it will fail to execute.

Regarding Ubuntu, see this issue where this behavior is discussed.


The history of this protection according to Wikipedia:

Sun Microsystems introduced rm -rf / protection in Solaris 10, first released in 2005. Upon executing the command, the system now reports that the removal of / is not allowed. Shortly after, the same functionality was introduced into FreeBSD version of rm utility. GNU rm refuses to execute rm -rf / if the --preserve-root option is given, which has been the default since version 6.4 of GNU Core Utilities was released in 2006.

share|improve this answer
    
+1: I didn't know that (and didn't try in a VM). So I guess my question is a bit late... –  Laurent Pireyn Sep 15 '11 at 10:46
    
Could you specify the Linux distribution and version you used? –  Laurent Pireyn Sep 15 '11 at 10:47
    
@Laurent I edited my answer in the mean time. I'm on RHEL5.6 right now and it allows the command by default. –  Daniel Beck Sep 15 '11 at 10:49
    
And thanks to @slhck we now know why my RHEL doesn't like it, it's software from early 2006 AFAICT. –  Daniel Beck Sep 15 '11 at 10:50
    
@slhck I don't think so. –  Daniel Beck Sep 15 '11 at 10:51

Why is there no such safeguard in the rm command?

There are already three safeguards:

  • The -r switch, without which a directory can't be removed.
  • The -i switch, which, which verifies that you actually want to delete what you've asked to delete. Aliasing rm to rm -i turns that safeguard on unless you add the -f switch to turn it off.
  • File ownership, which prevents all users but root from deleting the root directory.

The Unix toolset is like a chainsaw: it was designed to do very powerful things and be wielded by people who understand what they're doing. Those who tread carelessly are likely to end up injuring themselves. This isn't to say that the experienced don't make mistakes, and obviously Sun and others feel that users with root need to be protected from themselves.

However shouldn't this specific case be an exception to that rule?

People have been asking why we can't put a blade guard over the rm chainsaw since at least the 1980s. (Probably longer, but my history with Unix doesn't go back any further than that.) You have to ask yourself more questions:

  • Since we're adding exceptions, what else should be considered sacred? Should we prevent recursive deletion of anything in the root directory to avoid equally-devastating mistakes like rm -rf /*? What about the user's home directory? What about /lib or /bin? Would we have to have a special version of rm to prevent these mistakes on systems with a nontraditional file system layout?

  • Where do we put the enforcement of these prohibitions? Just in rm or do we give the kernel that job? Since rm doesn't actually delete anything (it makes lots of calls to unlink(2) and rmdir(2) based on the arguments), there would be no way for the kernel to detect that rm was really gunning for / until the moment actually came to delete it. Since the only call to rmdir(2) that would ever succeed is when the target directory is empty, reaching that point with / would mean the system's already done for.

share|improve this answer
    
+1 Unix toolset is a chainsaw. –  ultrasawblade Feb 20 '13 at 1:04

I used to say this in every UNIX training session when it comes to rm(1):

Note that the default rm will not ask you "Are you sure (Y/N)". Always watch out and remember: With UNIX you're always sure!

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.