Uid 0 has unlimited access on a Unix or linux system. Personally, I have never seen a Unix system where uid 0 is not named root, but the name should not matter. The celebrity of the system, root is who everyone wants to be. This everyone includes many people who would like to use the power of the system for their own purposes, not necessarily benevolent. Thus it is very important to treat access to this account with great respect, to limit its use whenever possible, and to protect it from being accessed surreptitiously. It is also important to provide as much monitoring of the use of root as possible.

By convention the prompt changes when you run as root. As root, the $ character in the normal prompt changes to a #. This, however, is configurable on any account by the owner of the account. Anyone can put a # in their prompt.

Logging in as root

Traditionally, users became root by logging on as root directly. This is a very bad idea for two reasons:

• when you log on as root, especially remotely, the tendency is to perform many operations as root that do not require root privileges, to avoid having to log out and log back in as a normal user. This multiplies the possibility of a grievous mistake. This is because of the habitual overuse by many users of two mechanisms:

• the asterisk (*) wildcard operator

• the -r option for rm

which could easily be mistyped since the key for a period is very close to the space bar.

• logging in directly as root is anonymous. It is impossible to determine who is actually logging in. 

In situations where you must become root and perform operations in the shell, it is much better to become root temporarily using the su command.

Using su to become root

The su command changes the effective user (euid) and group id (egid) (we will discuss this difference in the section on set-uid and set-gid) to another user and runs a shell. Commonly confused with superuser, the substitute user command su is normally invoked as 

su [ - ]  [user]

Here, if no alternate user name is given, it defaults to root.  su requests the password for the user. If the password is correct, it changes its euid and egid appropriately  and runs the user's default shell.  The - option, which is shorthand for -l, indicates that a login shell should be run. Otherwise, a non-login shell is run. Use of this option determines which initialization files are read by the new shell. Without the use of - , the new shell will get a copy of the current shell's environment variables (including PATH), umask, current directory, etc. If - is used, the shell initialization will reinitialize these parameters, since the /etc/profile file will be re-sourced as well as ~/.bash_profile. The two most important effects of this have to do with the PATH and current directory:

Traditionally, directories containing system administration commands were not in the PATH of normal users, although current releases of linux have changed this practice. If the sysadmin directories are not in your PATH when you run the su command, you won't have them in your PATH when you become root! This is alleviated by resetting your PATH to root's PATH using su -

One underutilized feature of su is to pass the shell it creates a single command. This is done with the -c command option. For example, suppose you need to become root momentarily to edit a configuration file:

su - -c 'vi /etc/xxx.conf' 

The su command would ask for root's password, login as root, execute the vi command, and, when vi exits, would exit the root shell. (Note that if this is an attempt to restrict root access, this solution has a serious flaw, as we will see later.) Note the absolute path of the file to edit. This is necessary because the - option has been used, which changes directory to root's home directory. 

Another case is 

su -c 'chmod 755 configfile'

In this case, configfile is in the current directory. This is ok since the - option was not given, and the current directory of the new shell does not change when the new shell starts.

Although the su command is usually used without a command to run, resulting in the execution of a root shell, becoming root via su is highly recommended compared to logging in as root directly due to two reasons:

• when you exit the root shell, you return to the parent shell. This makes it easy to execute a few commands as root then return to your normal account:

• use of the su command is usually logged in the system log file. Thus you have a record of who logged in as root and how long they were logged in as root (as log-off is also logged). Although while the suspect user is root he or she can easily alter the system logs, the messages can be logged remotely to protect them to a system inaccessible to the suspect user.

Protecting the root account

The root password is the most sensitive piece of information on your system. Protect it. Here are some do's and don'ts:

• only give it to people as necessary. Remember, it's like giving someone the code to your bank account while you're on vacation.
• if someone who needed it no longer needs it, change it
• in any case, change it from time to time.
• never leave your terminal unattended while it is logged in as root, even for a moment. This is all the time it takes to execute the following commands:

• create the password carefully so that you can remember it, others cant guess it, and you dont have to write it down. Mixed characters from the words of a sentence that you can remember is a simple technique. Dont forget to add some numbers or special characters.

In short

Avoid whenever possible giving anyone else the root password. Although they require some configuration, there are effective, manageable methods to provide someone with the privileges they need and avoid giving away the store. This is the subject of the future sections. Next, however, we will examine the effective use of permissions to avoid having to give away privileges.