sudo rm -rf /home
How to delete everything without warning
This is an ongoing series. Please check out the collection for the rest of the articles.
In the last two posts, I introduced the command line interface, or terminal, and gave a brief tour of some of the things it lets you do. In this post we’re going to talk about what it doesn’t let you do. I’m not talking about broken code or lack of features, though; I’m talking about security. Specifically, I’m going to introduce the basics of access permissions, the set of rules and procedures that dictates what you can and can’t do to the file system. (If all of this sounds like nonsense, I encourage you to start reading from an earlier post).
I ended the last article with an astounding fact: if your account has the right privileges, you can issue a single, short command to delete the personal files of every account in the operating system, even if there are hundreds of users in a shared network.
As you might have guessed from the title, this doomsday command is the following:
Remember from last time that rm removes any files you pass to it. -rf is a concise way of writing -r -f, two options you can pass to rm. -r stands for “recursive” and tells rm to remove whatever you give it, file or directory, and recursively remove everything inside it. So if you pass it the directory ~/UCS then ~/UCS and every file and directory within it is deleted. -f stands for force, and overrides certain safeguards that might have prevented some things from being deleted. As mentioned last time, /home stores the personal files of every user on the system — each user gets a directory within home that stores their files, e.g. /home/jack.
The question, then, is what sudo means. sudo is a portmanteau of “substitute user” and “do”. Accordingly, sudo performs whatever task you place after it as if you were another user. So
would temporarily switch your privileges to another user’s and then runs ls, reverting back to your normal privileges after ls finishes. By default, sudo switches your privileges to those of the root user or superuser. Of course, not just anyone can run sudo; before running any commands, sudo will ask you for your password. It then checks if you’re allowed to run programs as a superuser, refusing to run the command if you’re not.
A natural question to ask is why Linux bothers with such a security check, especially on a personal computer. If it’s your operating system, why do you need to have special privileges to do certain things? There are a number of reasons, listed here in no particular order:
- Safety: it is very unlikely that you’ll actually want to delete all of your personal files at once. It’s much more likely that you meant to do something less destructive. Forcing you to preface potentially harmful commands with sudo minimizes these kinds of accidents.
- Security: to stop viruses and other malicious software from easily usurping your computer. If a virus needs your password to get permission to wreak havoc, it is much less likely to succeed than if it were unleashed in an unprotected system.
- Compartmentalization (a mix of safety and security): many components of an operating system should not be disturbed by non-essential programs. By preventing programs running without superuser privileges from directly accessing hardware and other essential features, the chance that a poorly written program accidentally tampers with your internet access drops dramatically.
Additionally, since many operating systems host multiple users, sequestering important privileges from ordinary users prevents accidental and malicious interference with other users’ data. But access permissions is more elaborate than a simple division between super and non-super users; if you create a file, you can control who, if anyone, can read, write, and run your files, directories, and programs. Every item in the operating system can be configured to allow any combination of these permissions. The only exception is that the superuser (there’s usually just one) can do whatever they want with your files. When it comes to everyone else, however, you’re in control.
You might remember from a couple of posts ago that ls has an option, -l, that prints detailed information about each item it lists:
The first column shows each item’s access permissions. Let’s examine the permissions of coder.py in detail. Note that you can print the details of individual files by passing them to ls like this
The first character specifies what kind of item we’re looking at. Normal files are labeled with a ‘-’ and directories with a ‘d’. There are other kinds of files but discussing them would be more distracting then informative. Rest assured, we’ll get to them eventually.
The next 9 characters are divided into three sections of three characters each. These sections are called octets because they are made of 8 bits (oct- being the Greco-Roman root for eight). The final character in the column has to do with a fairly obscure concept we won’t be discussing this post.
Each octet specifies the permissions for a different subset of users. The first octet indicates what the file owner can do with the file, the second octet indicates what the group that owns the file can do, and the third octet indicates what everyone else can do. Groups are a way of — you guessed it — grouping users into different categories, usually with regards to what permissions they have. Users can belong to multiple groups and they can set the group ownership of any file they own to any group they belong to.
Let’s talk about what each of the 3 characters (or bits) of an octet mean. The 3 characters are ‘r’, ‘w’, and ‘x’, which stand for “read”, “write”, and “execute”, respectively. If the contents of a file can be read, the “read” bit is set to 1; if they can’t, the bit is set to 0. ‘r’ corresponds to 1 and ‘-’ corresponds to 0. The same logic applies to the other two bits as well. ‘w’ indicates that the contents of a file can be modified and ‘x’ indicates that the file can be run as a program (i.e. it can be executed), while ‘-’ means the respective permission is disabled.
Let’s explicitly state the permissions of coder.py, shown again for convenience:
First, this tells us that coder.py is a normal file. For the file owner (which you can see in a later column is “jack”), the file can be read and written to (this is the first octet). Anyone who belongs to the group that owns the file can also read and write to the file — they cannot execute it (this is the second octet). Everyone else is only allowed to read the file (this is the third octet).
As a somewhat technical aside, the permissions for a directory use the same characters that file permissions do — ‘r’, ‘w’, and ‘x’ — but have different meanings. ‘r’ indicates that the names of the directory’s contents can be listed; that is, calling ls on the directory will show the contents. But if ‘x’ is not also set, the metadata about these contents — their permissions, file size, etc. — cannot be seen. So calling ls -l on a directory that can be read but not executed will not show you file details (a bunch of question marks appear in their steads). ‘w’ allows the directory’s contents to be modified, renamed, and removed — if it’s not set, the contents of the directory can’t be tampered with.
The last paragraph contains a lot of technical information that you don’t need to memorize. You should be aware that nuances like these exist, though. For instance, you should remember that permissions mean different things for directories than for files, even if you don’t remember exactly what these differences are. In a similar vein, you don’t need to worry too much about modifying a file’s permissions. The default values that are applied when a file is created are usually fine; but it’s worth knowing that you can change these values when needed, like when you want to hide super-secret intel from prying eyes or let someone else edit your stuff.
To finish off, let me show you how to modify these permissions you’ve learned about. The program is called chmod, which is a shortening of “change mode”. To make a file executable (which you’ll need to do for some script files), call chmod with a +x like this:
This sets the ‘x’ bit for the file owner of your-program, allowing the file to be run as a program. Use -x to take away executability. You can probably infer that the ‘r’ and ‘w’ bits can be modified in the same way. And remember, if you want to know more about a shell program, use the manual:
We’ll certainly return to more advanced access permissions down the road, but this is more than enough knowledge to start with. Next time, I’ll introduce you to Python, an excellent scripting language to learn, especially as a beginner.
If you’ve installed Fedora and want to get a head start, you can install python with the following command:
You can play around with the language by simply entering python in the shell. Notice that installing new programs requires superuser privileges!
Image credit: Dr. Strangelove
