Avoid Logging in As Root

By design, the root user has access to everything on a system. It is the workhorse account and must be used to perform the more intricate and dangerous tasks on a system. You might be tempted to use the root account all the time because it permits unfettered access to all the commands necessary for maintaining a system. The downside is that using it all the time also eliminates the warning flag the system generates when something dangerous is about to happen.

In the normal course of events, the system warns a typical user that he or she does not have the necessary privileges for performing a certain function. The warning serves two purposes: Restricting access to parts of the system (or particular functions) and identifying the command requested can have significant repercussions. If the root account is used, many of these warnings are suppressed, and possible repercussions are not flagged. A simple keystroke can turn a simple command into a disaster.

It is therefore a good system management practice to use the root account as little as possible. It is also important to keep the root account restricted to a minimum number of individuals and locked down to the console. Auditing the use of a generic account such as root is difficult if not impossible. There are few business reasons for numerous individuals to have complete access to all the directories and files on a system. In a mission-critical system, it is not uncommon to have only one individual allocated to root.

In Chapter 5, "User Environment Management and Security," we explored the use of the su and sudo commands as appropriate replacements for the root account. When appropriate, the su command can be used to attain root access to the system. Access to the su command can be restricted and requires knowledge of the root password. Once granted, however, this level of access is equivalent to the root user and should therefore be strictly controlled. A more granular method for granting elevated privileges is to use the sudo environment. Within sudo, permission to individual commands can be granted allowing the users to perform the tasks they need to perform while restricting them from unnecessary access.

To see how to replace root access with sudo access, explore the following example. In many cases, users need to bulk-upload information to a server. In these cases, you may need to grant physical access to the server and provide a mechanism for mounting the volume.

If an operator is available and has the time, he or she could mount the volume for the user, move the data from the CD to the appropriate target directory, and then reset the permissions on the files.

More typically, the user would be responsible for moving the data. By default, SLES does not allow users to mount removable media. There are two ways of working around this situation. The first is to change the definition of the /dev/cdrom mount point in /etc/fstab to allow the addition of the user option. With this flag, nonprivileged users can mount and umount the CD at will. The problem with this solution is that it grants access to the CD drive to all users on the system. This may or may not be a satisfactory solution.

A more refined approach is to grant, through sudo, the right to use the mount command. In this way, you can selectively target specific users with the appropriate rights to access specific devices without having to grant access to all users.

Though the root account must be used in some situations, many more instances can be satisfied by using sudo. Restricting assess privileges enhances the robustness of the server. If a business practice requires a user to have enhanced access, other mechanisms are available to satisfy the need rather than sharing the root account.