8

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?

Community
  • 1
Laurent Pireyn
  • 201

2 Answers2

25

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

fuenfundachtzig
  • 867
Blrfl
  • 519
17

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.

Daniel Beck
  • 111,893