How is 'rm -rf /' able to delete all files in the system?
It doesn't matter that /bin/rm is deleted. It's only being run once and by that point it's all loaded in memory, as is everything else required to keep sending deletes to the filesystem and disk.
Sidebar/Update: Per David Hoelzer's answer (and mentioned in the comments), the inode the hardlink /bin/rm used to point to would remain right up until rm finished (because Linux holds in an open state) but that fact is irrelevant; the state of the disk doesn't matter at all.
The binary is loaded into memory before it is run. Even if you could manually destroy the rm disk data, it wouldn't affect or stop the deletion from completing (assuming you don't otherwise make the disk unavailable).
No idea what an inode or hardlink are? This is the answer where I worked it out.
Anyway, this is also why you can delete the package for the current kernel without the computer imploding. As long as you install a different version, it'll be able to boot up.
Again, this works because rm is only called once. The following would fail after /bin/rm died because it calls it once for every filename:
find / -exec rm {} \;
That said, find / -exec rm -rf {} + and find / -print0 | xargs -0 rm -rf would also both likely fail because they both have argument limits, meaning they would only delete a number of files before being called again. At some point along the journey, /bin/rm could expire (and be released) before the rest of the files were deleted. It's not guaranteed though. If /bin/ were the last directory entered, these methods could work.
I haven't tried this command on Ubuntu (for obvious reasons) so I am not sure if Ubuntu will allow its execution.
I did. rm -rf / --no-preserve-root was running in a root session opened directly on the machine, while I was also connected through ssh from another machine, using the root account as well.
What happens is that you start to get a lot of messages like:
rm: cannot remove '/...': Operation not permitted
or:
rm: cannot remove '/...': Device or resource busy
Surprisingly, ssh connection remained opened until the end of the operation. It's only when I closed the connection and tried to reopen it that a error appeared:
Read from socket failed: Connection reset by peer
On the machine, four directories remain:
/dev. This is where device files are stored./proc—in-memory filesystem created by the kernel./run, a standardized file system location for daemons./sys. This allows you to get information about the system and its components.
This means that there is not much left, and not much to do there. You can't ls (although when using Tab, the names of directories and files are still displayed). You can cd in different directories, and also echo stuff, but commands such as cat are not available any longer.
There is no sudo either.
shutdown -h now and reboot disappeared as well, so your only option seems to turn the machine down manually. Logout (exit) doesn't work, even if it shows a nice "logout" text.
Once you try to reboot the machine, you're presented with a nice GRUB error 15, and then, nothing happens, at which point you may start thinking that your rm might have done something bad to your system.
You can do it too
No, wait, don't do it on your machine!
What you can do instead is to run a virtual machine. VMs have a benefit of making experimentation really easy. Since you are using Ubuntu, you may be interested by vmbuilder. This is a tool which allows you to deploy virtual machines in a matter of minutes (the official documentation claims that it can be done "in about a minute", but the actual time, even on fast hardware, is more about two-three minutes.
Once the deployment ends, you have an environment you can play with. If you end up destroying it, it doesn't matter: you deploy the machine again, and two minutes later you can continue.
If you use software such as VMWare, you may also be interested in snapshots (note that the free VMWare Player doesn't have this feature; you have to purchase VMware Workstation). Note that Hyper-V is free and supports snapshots (but you have to run Windows).
The benefit of snapshots is that you can take one in a matter of milliseconds. Rolling back to a snapshot takes longer, but is often a matter of seconds. This makes experimentation even easier and faster.
This experimentation is not limited to the operating system itself. You can do all sort of things involving software. Got a suspicious application? Test it in a VM—if it's a virus, it won't do any harm. Want to test an operation on a database, given that it might affect the environment? Test it in a VM.
What if you did that on a real, non-test machine?
Bad things happen. Note that rm protects you from yourself: rm -rf / won't work: you need to use --no-preserve-root. Still, what if you actually achieved, by mistake, to remove everything?
rm only unlinks files, but the data is still there, on your hard disk. This makes it possible to recover it later (which is why you shouldn't just throw away your hard disks with sensitive data when they are not working any longer).
This means that you just have to have a spare PC with a hard drive enclosure to actually recover nearly all the files. The important thing is to avoid writing anything to the hard disk to recover: the data you write will overwrite the unlinked files.
As noted by the article in 200_success's comment, if you act smart, you can get the machine back even without a spare PC. If you care just about data, I wouldn't bother—recovering it with a spare PC is much easier.
The reason is that the file naming layer (what you see with ls) is really just for your convenience. The file system driver and kernel care only what the inode is. When a file is referenced by name, it is immediately translated into the inode which contains all of the metadata including the permissions, the data blocks on the disk, the owner ID, the group ID and the link count.
The link count is what really matters here. When you delete a file on a UNIX system, the actual system call is an unlink. What's happening under the hood is that the link count (the number of file names in the file naming layer) pointing at that inode is decremented. The file system knows that a file is deleted when the link count reaches zero.
When a file is deleted by rm it will also edit the directory file (yes, it's just a file that contains the file name and the inode in addition to a few other bits that are not important for this answer). However, it is the unlinking that actually frees the disk resources.
This leads to some other interesting effects. First, it is possible to have a file open whose link count is zero. This happens when rm -rf / deletes the entry for /bin/rm. The file is open (there is a file handle to it) but the inode is marked deleted (link count = 0). The disk resources will not be released and reused until the file handle closes.
Another interesting effect is what happens when you have an inode with a link count greater than zero but nothing in the file naming layer that points to it. This is, in a sense, a very well hidden file :). To get access to it you would have to use something low level to reference it by inode number rather than by name (because there isn't one) or edit a directory entry to point at the inode using a hex editor.
A third interesting effect is what happens if you reduce the link count to zero but point a directory entry at the inode anyway. I'll leave that to you to experiment with if you'd like. Clearly, though, these last two both lead to the file system being in an inconsistent state.