"rm -rf /" protection

Most people who have spent any time on any version of Unix know that "rm -rf /" is about the worst mistake you can make on any given machine. (For novices, "/" is the root directory, and -r means recursive, so rm keeps deleting files until the entire file system is gone, or at least until something like libc is gone after which the system becomes, as we often joke, a warm brick.) Well a couple of years ago one Friday afternoon a bunch of us were exchanging horror stories on this subject, when Bryan asked "why don't we fix rm?" So I did.

The code changes were, no surprise, trivial. The hardest part of the whole thing was that one reviewer wanted /usr/xpg4/bin/rm to be changed as well, and that required a visit to our standards guru. He thought the change made sense, but might technically violate the spec, which only allowed rm to treat "." and ".." as special cases for which it could immediately exit with an error. So I submitted a defect report to the appropriate standards committee, thinking it would be a slam dunk.

Well, some of these standards committee members either like making convoluted arguments or just don't see the world the same way I do, as more than one person suggested that the spec was just fine and that "/" was not worthy of special consideration. We tried all sorts of common sense arguments, to no avail. In the end, we had to beat them at their own game, by pointing out that if one attempts to remove "/" recursively, one will ultimately attempt to remove ".." and ".", and that all we are doing is allowing rm to pre-determine this heuristically. Amazingly, they bought that!

Anyway, in the end, we got the spec modified, and Solaris 10 has (since build 36) a version of /usr/bin/rm (/bin is a sym-link to /usr/bin on Solaris) and /usr/xpg4/bin/rm which behaves thus:

[28] /bin/rm -rf /
rm of / is not allowed
[29] 
Comments:

John,

Wow, it's these little nits that really make UNIX difficult for some folks that don't use it all the time. This is so logical, it seems that must be the reason it's been overlooked all these years!

Posted by Alan DuBoff on October 01, 2004 at 03:15 PM PDT #

I just wanted you to know that this "feature" almost ruined one of my demos :)

I tried to show that "blowing away a zone" would not affect other zones. You made it harder to blow away a zone. It's good for the real world, but not for demo's. I recovered by blowing away /var and /etc ... :)

Posted by John Clingan on October 01, 2004 at 04:04 PM PDT #

Just as long as "rm -rf \*" still works while sitting in "/". :) Gotta make sure that typos like "rm -rf file \*" still wreak havoc!

Posted by Kevin on October 02, 2004 at 09:04 AM PDT #

You know, I've always held a special place in my heart for whoever it was at Sun that came up with
<code>
smilodon[/]# kill -9 1
kill: 1: permission denied
smilodon[/]#
</code>
This just takes it a little bit farther. Thanks!

Posted by Pete Ehlke on October 05, 2004 at 12:18 AM PDT #

You know, I've always held a special place in my heart for whoever it was at Sun that came up with
<code>
smilodon[/]# kill -9 1
kill: 1: permission denied
smilodon[/]#
</code>
This just takes it a little bit farther. Thanks!

Posted by Pete Ehlke on October 05, 2004 at 01:36 AM PDT #

Okay, just how far are we going to dumb things down to accommodate the lowest common denominator, i.e. the STUPID USER?

Now, granted, I \*did\* watch someone try to remove a directory under root whose name was " " (that's a space, folks), so they typed

<code> # rm -rf / </code>
[That's slash-space....]

But you know something? With a little thought, that could have been avoided.

If you don't think about what you do as a normal user, let alone the super-user, you deserve what you get.

This is just so mind-numbingly STUPID an idea, it boggles me.

This is up there with 'kill -9 1' returning EACCES instead of just silently returning (which it should do), as well as the earliest versions of Solaris 2 (born from that abomination known as System V) which couldn't even divine the proper run level when you exited single-user mode.

Or how about the idea of making everything as much as possible dynamically linked so that if libc.so\* or ld.so or /dev/zero go bye bye for some reason, the system turns into (as described above) a warm brick? Dynamically linked /usr/sbin/mknod? Come on. That was real genius at its finest.

[never mind that sleeping with AT&T wasn't the brightest idea the Sun Standards and Engineering team had, either, but we're stuck with it. --Ed]

Posted by Greywolf on October 05, 2004 at 10:06 AM PDT #

Sigh. I wish I had seen this comment earlier. Greywolf, you're making a pretty strong assumption: that the culprit is the end user, and is somehow some dumb idiot who should have known better.

In fact, I was once the victim of a (very large) shell script, one line of which was coded as follows:

rm -fr ${X}/${Y}

I did not author this script; it came from an otherwise well respected software vendor. Given the script logic, it wasn't uncommon for $X to be an empty string, but $Y was supposed to be the pathname of a subdirectory to remove. In one instance, the script logic failed, and $Y wound up unset. As a result, this expression boiled down to: <tt>rm -fr /</tt>, and it nuked my machine.

I won't incriminate the vendor whose script this was, but I will tell you that I was none too pleased with the outcome. Since I work with John and Bryan, and they well know this story, this is partly how this idea came about.

So I'm sorry that you think this is "mind-numbingly stupid" but we arrived at it based on catastrophic real-world experience. In my personal opinion, if it saves even one customer's machine, it will have been worth the effort.

Also, I must say that I feel that the tone and content of your comments is somewhat out of proportion to the relative significance of this change. It seems like your reasons for disliking this are grounded more in an implied ad hominem attack against Sun's engineers than the actual content of the change.

Posted by Daniel Price on October 30, 2004 at 07:23 PM PDT #

Well, IMO anyone who writes "rm -fr ${X}/${Y}" without considering the possibility of both vars being empty should be shot. You should've nuked the vendor who wiped your computer (I guess it would've been hard to debug the script after everything was gone) This is indeed a trivial change and not one that should affect everyday life. But UNIX was always appreciated for its role as an swift and unforgiving teacher. If users need to be protected from themselves, use non-root accounts and a GUI. Windows has "del /s/q/f" and "rmdir /s/q" I wonder what would happen if... (We all know Windows keeps files locked so the damage is limited. Is that the next wave?)

Posted by Jackie London on October 31, 2004 at 06:15 AM PST #

this is brilliant -- but it's going to spoil an awful lot of my fun. :-) man, i wish i was in a position to just fix things like that.

Posted by sabrina on November 10, 2004 at 10:18 AM PST #

Post a Comment:
Comments are closed for this entry.
About

jbeck

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today