Being the system administrator for any Unix system requires a certain degree of responsibility and care. This is equally true for Linux, even if you’re the only user on your system.

Many of the system administrator’s tasks are done by logging into the root account. This account has special properties on Unix systems; specifically, the usual file permissions and other security mechanisms simply don’t apply to root. That is, root can access and modify any file on the system, no matter to whom it belongs. Whereas normal users can’t damage the system (say, by corrupting filesystems or touching other users’ files), root has no such restrictions.

At this point, it should be mentioned that some distributions, such as Ubuntu, disable the root account and require users to use the sudo tool instead. With sudo, you cannot log in as root, but you can execute exactly one command with the rights of root, which amounts to the same thing, except that you have to prefix each command with sudo.

Why does the Unix system have security in the first place? The most obvious reason for this is to allow users to choose how they wish their own files to be accessed. By changing file permission bits (with the chmod command), users can specify that certain files should be readable, writable, or executable only by certain groups of other users, or by no other users at all. Permissions help ensure privacy and integrity of data; you wouldn’t want other users to read your personal mailbox, for example, or to edit the source code for an important program behind your back.

The Unix security mechanisms also prevent users from damaging the system. The system restricts access to many of the raw device files (accessed via /dev--more on this in "Device Files" later in this chapter) corresponding to hardware, such as your hard drives. If normal users could read and write directly to the disk-drive device, they could wreak all kinds of havoc — say, completely overwriting the contents of the drive. Instead, the system requires normal users to access the drives via the filesystem—where security is enforced via the file permission bits described previously.

It is important to note that not all kinds of “damage” that can be caused are necessarily malevolent. System security is more a means to protect users from their own natural mistakes and misunderstandings rather than to enforce a police state on the system. And, in fact, on many systems security is rather lax; Unix security is designed to foster the sharing of data between groups of users who may be, say, cooperating on a project. The system allows users to be assigned to groups, and file permissions may be set for an entire group. For instance, one development project might have free read and write permission to a series of files, while at the same time other users are prevented from modifying those files. With your own personal files, you get to decide how public or private the access permissions should be.

The Unix security mechanism also prevents normal users from performing certain actions, such as calling certain system calls within a program. For example, there is a system call that causes the system to halt, called by programs such as shutdown (more on this later in the chapter). If normal users could call this function within their programs, they could accidentally (or purposefully) halt the system at any time.

In many cases, you have to bypass Unix security mechanisms in order to perform system maintenance or upgrades. This is what the root account is for. Because no such restrictions apply to root, it is easy for a knowledgeable system administrator to get work done without worrying about the usual file permissions or other limitations. The usual way to log in as root is with the su command. su allows you to assume the identification of another user. For example:

    su andy

will prompt you for the password for andy, and if it is correct it will set your user ID to that of andy. A superuser often wants to temporarily assume a regular user’s identity to correct a problem with that user’s files or some similar reason. Without a username argument, su will prompt you for the root password, validating your user ID as root. Once you are finished using the root account, you log out in the usual way and return to your own mortal identity.^[*]

Why not simply log in as root from the usual login prompt? As we’ll see, this is desirable in some instances, but most of the time it’s best to use su after logging in as yourself. On a system with many users, use of su records a message, such as:

    Nov  1 19:28:50 loomer su: mdw on /dev/ttyp1

in the system logs, such as /var/log/messages (we talk more about these files later). This message indicates that the user mdw successfully issued an su command, in this case for root. If you were to log in directly as root, no such message would appear in the logs; you wouldn’t be able to tell which user was mucking about with the root account. This is important if multiple administrators are on the machine: it is often desirable to find out who used su and when.

There is an additional little twist to the su command. Just running it as described previously will only change your user ID; it will not give you the settings made for this ID. You might have special configuration files for each user, but these are not executed when using su this way. To emulate a real login with all the configuration files being executed, you need to add a -, like this:

    su - andy

or:

    su -

for becoming root and executing root’s configuration files.

The root account can be considered a magic wand—both a useful and potentially dangerous tool. Fumbling the magic words you invoke while holding this wand can wreak unspeakable damage on your system. For example, the simple eight-character sequence rm -rf / will delete every file on your system, if executed as root, and if you’re not paying attention. Does this problem seem far-fetched? Not at all. You might be trying to delete an old directory, such as /usr/src/oldp, and accidentally slip in a space after the first slash, producing the following:

    rm -rf / usr/src/oldp

Also problematic are directory names with spaces in them. Let’s say you have directories named Dir\ 1 and Dir\ 2, where the backslash indicates that Dir\ 1 is really one filename containing a space character. Now you want to delete both directories, but by mistake add an extra space again:

    rm -rf Dir\  *

Now there are two spaces between the backslash and the asterisk. The first one is protected by the backslash, but not the second one, so it separates the arguments and makes the asterisk a new argument. Oops, your current directory and everything below it are gone.

Another common mistake is to confuse the arguments for commands such as dd, a command often used to copy large chunks of data from one place to another. For instance, in order to save the first 1024 bytes of data from the device /dev/hda (which contains the boot record and partition table for that drive), one might use the command:

    dd if=/dev/hda of=/tmp/stuff bs=1k count=1

However, if we reverse if and of in this command, something quite different happens: the contents of /tmp/stuff are written to the top of /dev/hda. More likely than not, you’ve just succeeded in hosing your partition table and possibly a filesystem superblock. Welcome to the wonderful world of system administration!

The point here is that you should sit on your hands before executing any command as root. Stare at the command for a minute before pressing Enter and make sure it makes sense. If you’re not sure of the arguments and syntax of the command, quickly check the manual pages or try the command in a safe environment before firing it off. Otherwise you’ll learn these lessons the hard way; mistakes made as root can be disastrous.

A nice tip is to use the alias command to make some of the commands less dangerous for root. For example, you could use:

    alias rm="rm -i"

The -i option stands for interactively and means that the rm command will ask you before deleting each file. Of course, this does not protect you against the horrible mistake shown earlier; the -f option (which stands for force) simply overrides the -i because it comes later.

In many cases, the prompt for the root account differs from that for normal users. Classically, the root prompt contains a hash mark (#), whereas normal user prompts contain $ or %. (Of course, use of this convention is up to you; it is utilized on many Unix systems, however.) Although the prompt may remind you that you are wielding the root magic wand, it is not uncommon for users to forget this or accidentally enter a command in the wrong window or virtual console.

Like any powerful tool, the root account can be abused. It is important, as the system administrator, to protect the root password, and if you give it out at all, to give it only to those users who you trust (or who can be held responsible for their actions on the system). If you’re the only user of your Linux system, this certainly doesn’t apply—unless, of course, your system is connected to a network or allows dial-in login access.

The primary benefit of not sharing the root account with other users is not so much that the potential for abuse is diminished, although this is certainly the case. Even more important is that if you’re the one person with the ability to use the root account, you have complete knowledge of how the system is configured. If anyone were able to, say, modify important system files (as we’ll talk about in this chapter), the system configuration could be changed behind your back, and your assumptions about how things work would be incorrect. Having one system administrator act as the arbiter for the system configuration means that one person always knows what’s going on.

Also, allowing other people to have the root password means that it’s more likely someone will eventually make a mistake using the root account. Although each person with knowledge of the root password may be trusted, anybody can make mistakes. If you’re the only system administrator, you have only yourself to blame for making the inevitable human mistakes as root.

That being said, let’s dive into the actual tasks of system administration under Linux. Buckle your seatbelt.