System Administrator and Superuser | A Practical Guide to Red HatВ® LinuxВ®: Fedoraв„ў Core and Red Hat Enterprise Linux (3rd Edition)

Much of what a system administrator does is work that ordinary users do not have permission to do. When performing one of these tasks, the system administrator logs in as root (or uses another method; see the list starting on page 392) to have systemwide powers that are beyond those of ordinary users: A user with root privileges is referred to as Superuser. The username is root by default. Superuser has the following powers and more:

Some commands, such as those that add new users, partition hard drives, and change system configuration, can be executed only by root. Superuser can use certain tools, such as sudo, to give specific users permission to perform tasks that are normally reserved for Superuser.
Read, write, and execute file access and directory access permissions do not affect root: Superuser can read from, write to, and execute all files, as well as examine and work in all directories.
Some restrictions and safeguards that are built into some commands do not apply to root. For example, root can change any user's password without knowing the old password.

When you are running with root (Superuser) privileges, the shell by convention displays a special prompt to remind you of your status. By default this prompt is or ends with a pound sign (#).

To lessen the chance that a user other than Superuser will try to use them by mistake, many of the utilities that Superuser runs are kept in the /sbin and /usr/sbin directories, rather than in /bin and /usr/bin. (Many of these utilities can be run by ordinary users.) You can execute these utilities by giving their full pathnames on the command line (for example, /sbin/runlevel). When you log in as root, these directories are in your PATH (page 292) by default.

Caution: Least privilege

When you are working on the computer, especially when you are working as the system administrator, perform any task by using the least privilege possible. When you can perform a task logged in as an ordinary user, do so. When you must be logged in as Superuser, do as much as you can as an ordinary user, log in or use su so that you have root privileges, complete the part of the task that has to be done as Superuser, and revert to being an ordinary user as soon as you can. Because you are more likely to make a mistake when you are rushing, this concept becomes more important when you have less time to apply it.

You can gain or grant Superuser privileges in a number of ways:

When you bring the system up in single-user mode (page 409), you are Superuser.
Once the system is up and running in multiuser mode (page 410), you can log in as root. When you supply the proper password, you will be Superuser.
You can give an su (substitute user) command while you are logged in as yourself and, with the proper password, you will have Superuser privileges. For more information refer to "su: Gives You Another User's Privileges" on page 393.
You can use sudo selectively to give users Superuser privileges for a limited amount of time on a per-user and per-command basis. The sudo utility is controlled by the /etc/sudoers file, which must be set up by root. Refer to the sudo man page for more information.
Any user can create a setuid (set user ID) file (page 183). Setuid programs run on behalf of the owner of the file and have all the access privileges that the owner has. While you are running as Superuser, you can change the permissions of a file owned by root to setuid. When an ordinary user executes a file that is owned by root and has setuid permissions, the program has full root privileges. In other words, the program can do anything that root can do and that the program does or allows the user to do. The user's privileges do not change. When the program finishes running, all user privileges revert to the way they were before the program started. Setuid programs that are owned by root are both extremely powerful and extremely dangerous to system security, which is why a system contains very few of them. Examples of setuid programs that are owned by root include passwd, at, and crontab. The following example shows two ways for Superuser to give a program setuid privileges:
```
# ls -l my* rwxrxrx   1 root     other       24152 Apr 29 16:30 myprog rwxrxrx   1 root     other       24152 Apr 29 16:31 myprog2 #  chmod 4755 myprog #  chmod u+s myprog2 # ls -l my* rwsrxrx   1 root     other       24152 Apr 29 16:30 myprog rwsrxrx   1 root     other       24152 Apr 29 16:31 myprog2
```
The s in the owner execute position of the ls l output (page 181) indicates that the file has setuid permission.
Security: root-owned setuid programs are extremely dangerous

Because a root-owned setuid program allows someone who does not know the root password to have the powers of Superuser, it is a tempting target for a malicious user. A system should have as few of these programs as necessary. You can disable setuid programs at the filesystem level by mounting a filesystem with the nosuid option (page 467). You can also use SELinux (page 400) to disable setuid programs. See page 399 for a command that lists setuid files on the local system.
Some programs ask you for a password (either your password or the root password, depending on the particular command and the configuration of the system) when they start. When you provide the root password, the program runs with Superuser privileges.
When a program requests the root password when it starts, you stop running as the privileged user when you quit using the program. This setup keeps you from remaining logged in as Superuser when you do not need or intend to be. Refer to "consolehelper: Runs Programs as root" on page 394.

Some techniques limit the number of ways to become Superuser. PAM (page 438) controls the who, when, and how of logging in. The /etc/securetty file controls which terminals (ttys) a user can log in on as root. The /etc/security/access.conf file adds another dimension to login control (see the file for details).

Security: Do not allow root access over the Internet

Prohibiting root logins using login over a network is the default policy of Red Hat Enterprise Linux and Fedora Core and is implemented by the PAM securetty module. The /etc/security/access.conf file must contain the names of all users and terminals/workstations that you want a user to be able to log in on as root. Initially every line in access.conf is commented out.

You can, however, log in as root over a network using ssh (page 579). As shipped by Red Hat, ssh does not follow the instructions in securetty or access.conf. Also, in /etc/ssh/sshd_config, Red Hat sets PermitRootLogin to YES (it is set by default) to permit root to log in using ssh (page 594).

System Administration Tools

Many tools can help you be an efficient and thorough system administrator. A few of these tools/utilities are described in this section, another group of administration utilities is described starting on page 415, and others are scattered throughout Part IV.

su: Gives You Another User's Privileges

The su (substitute user) utility can create a shell or execute a program with the identity and permissions of a specified user. Follow su on the command line with the name of a user; if you are root or if you know the user's password, you take on the identity of that user. When you give an su command without an argument, su defaults to Superuser so that you take on the identity of root (you have to know the root password).

To be sure that you are using the system's official version of su (and not one planted on your system by a malicious user), specify su's absolute pathname (/bin/su) when you use it. (Of course, if someone has compromised your system enough that you are running a fake su command, you are in serious trouble anywaybut using an absolute pathname for su is still a good idea.)

When you give an su command to become Superuser, you spawn a new shell, which displays the # prompt. You return to your normal status (and your former shell and prompt) by terminating this shell: Press CONTROL-D, or give an exit command. Giving an su command by itself changes your user and group IDs but makes minimal changes to your environment. You still have the same PATH you did when you logged in as yourself. When you run a utility that is normally run by root (the utilities in /sbin and /usr/sbin), you need to specify an absolute pathname for the utility (such as /sbin/service). When you give the command su (you can use l or login in place of the hyphen), you get a root login shell: It is as though you logged in as root. Not only are your user and group IDs those of root, but your entire environment is that of root. The login shell executes the appropriate startup scripts before displaying a prompt, and your PATH is set to what it would be if you had logged in as root, typically including /sbin and /usr/sbin.

Use the id utility to display the changes in your user and group IDs and in the groups you are associated with. In the following example, the information that starts with context pertains to SELinux:

$ id uid=500(alex) gid=500(alex) groups=500(alex) context=user_u:system_r:unconfined_t $ su Password: # id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys), ...

You can use su with the c option to run a single command with root privileges, returning to your original shell when the command finishes executing. The following example first shows that a user is not permitted to kill a process. With the use of su c and the root password, the user is permitted to kill (page 395) the process. The quotation marks are necessary because su c takes its command as a single argument.

$ kill -15 4982 -bash: kill: (4982) - Operation not permitted $ su -c "kill -15 4982" Password: $

consolehelper: Runs Programs as root

The consolehelper utility can make it easier for someone who is logged in on the system console but not logged in as root to run system programs that normally can be run only by root. PAM (page 438), which authenticates users, can be set to trust all console users, to require user passwords (not the root password), or to require root passwords before granting trust. The concept underlying consolehelper is that you may want to consider as trustworthy anyone who has access to the console. For example, Alex can log in on the console as himself and run halt without knowing the root password. For more information refer to the discussion of consolehelper on page 413 and to the consolehelper man page.

Security: Superuser, PATH, and security

The fewer directories you keep in your PATH when you are root, the less likely you will be to execute an untrusted program as root. If possible, keep only the default directories, along with /sbin and /usr/sbin, in root's PATH. Never include the working directory (as . or : : anywhere in PATH, or : as the last element of PATH). For more information refer to "PATH: Where the Shell Looks for Programs" on page 292.

kill: Sends a Signal to a Process

The kill builtin sends a signal to a process. This signal may or may not terminate (kill) the process, depending on which signal is sent and how the process is designed. Refer to "trap: Catches a Signal" on page 933 for a discussion of the various signals and their interaction with a process. Running kill is not the first method a user or system administrator should try when a process needs to be aborted.

Caution: kill: Use the kill signal (KILL or 9) as a method of last resort

When you do need to use kill, send the termination signal (kill TERM or kill 15) first. Only if that tactic does not work should you attempt to use the kill signal (kill KILL or kill 9).

Because of its inherent dangers, using a kill signal is a method of last resort, especially when you are running as Superuser. One kill command issued by root can bring the system down without warning.

Usually a user can kill a process by working in another window or by logging in on another terminal. Sometimes you may have to log in as root (or use su) to kill a process for a user. To kill a process, you need to know its PID. The ps utility can provide this information once you determine the name of the program the user is running and/or the username of the user. The top utility (page 550) can also be helpful in finding and killing (see top's k command) a runaway process.

In the following example, Sam complains that xeyes is stuck and that he cannot do anything from the xeyes window, not even close it. A more experienced user could open another window and kill the process, but in this case, you kill it for Sam. First use ps with the u option, followed by the name of the user and the f (full/wide) option to view all the processes associated with that user.

$ ps -u sam -f UID        PID  PPID  C STIME TTY          TIME CMD sam       2294  2259  0 09:31 ?        00:00:00 /bin/sh /usr/bin/startkde sam       2339  2294  0 09:31 ?         00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch sam       2342     1  0 09:31 ?         00:00:00 dbus-daemon --fork --print-pid 8 --prin sam       2343     1  0 09:31 ?         00:00:00 /usr/bin/dbus-launch --exit-with-sessio sam       2396     1  0 09:31 ?         00:00:00 kdeinit Running... sam       2399     1  0 09:31 ?        00:00:00 dcopserver [kdeinit] --nosid sam       2401  2396  0 09:31 ?         00:00:00 klauncher [kdeinit] sam       2403     1  0 09:31 ?        00:00:00 kded [kdeinit] sam       2405     1  0 09:31 ?        00:00:00 /usr/libexec/gam_server sam       2413  2396  0 09:31 ?         00:00:00 /usr/bin/artsd -F 10 -S 4096 -s 60 -m a sam       2415     1  0 09:31 ?         00:00:00 kaccess [kdeinit] sam       2416  2294  0 09:31 ?         00:00:00 kwrapper ksmserver sam       2418     1  0 09:31 ?         00:00:00 ksmserver [kdeinit] sam       2421  2396  0 09:31 ?         00:00:00 kwin [kdeinit] -session 1070626e6a00011 sam       2424     1  0 09:31 ?         00:00:01 kdesktop [kdeinit] sam       2426     1  0 09:31 ?        00:00:01 kicker [kdeinit] sam       2429  2396  0 09:31 ?         00:00:00 kio_file [kdeinit] file /tmp/ksocket-ma sam       2434  2396  0 09:31 ?         00:00:00 konsole [kdeinit] -session 1070626e6a00 sam       2435  2396  0 09:31 ?         00:00:00 /bin/sh /usr/lib/firefox-1.5/firefox -U sam       2446  2435  0 09:31 ?         00:00:00 /bin/sh /usr/lib/firefox-1.5/run-mozill sam       2451  2446  0 09:31 ?         00:00:01 /usr/lib/firefox-1.5/firefox-bin -UILoc sam       2453  2434  0 09:31 pts/2    00:00:00 /bin/bash sam       2474     1  0 09:31 ?        00:00:00 /usr/libexec/gconfd-2 10 sam       2482     1  0 09:32 ?         00:00:00 synergyc jam sam       3568  3567  0 13:55 pts/3     00:00:00 -bash sam       3726     1  0 14:07 ?         00:00:00 knotify [kdeinit] sam       3728     1  0 14:07 ?         00:00:00 /usr/bin/artsd -F 10 -S 4096 -s 60 -m a sam       3730  2424  0 14:07 ?         00:00:00 xeyes sam       3731  3568  0 14:07 pts/3     00:00:00 ps -u sam -f

This list is fairly short, and the process running xeyes is easy to find. Another way to search for a process is to use ps to produce a long list of all processes and then use grep to find which ones are running xeyes.

$ ps -ef | grep xeyes sam       3730  2424  0 14:07 ?        00:00:00 xeyes sam       3766  3568  0 14:14 pts/3    00:00:00 grep xeyes

If several people are running xeyes, you may need to look in the left column to find the name of the user so you can kill the right process. You can combine the two commands as ps u sam f | grep xeyes.

Now that you know Sam's process running xeyes has a PID of 3730, you can use kill to terminate it. The safest way to do so is to log in as Sam (perhaps allow him to log in for you or su to sam [su sam] if you are logged in as root) and give any of the following commands (they all send a termination signal to process 3730):

$ kill 3730

$ kill -15 3730

$ kill TERM 3730

Only if this command fails should you send the kill signal:

$ kill KILL 3730

The KILL option instructs kill to send a SIGKILL signal, which the process cannot ignore. You can give the same command while you are logged in as root, but a typing mistake can have much more far-reaching consequences in this circumstance than when you make the mistake while you are logged in as an ordinary user. A user can kill only her own processes, whereas Superuser can kill any process, including system processes.

As a compromise between speed and safety, you can combine the su and kill utilities by using the c option to su. The following command runs the part of the command line following the c with the identity of Sam:

# su sam -c "kill -TERM 3730"

Two useful utilities related to kill are killall and pidof. The killall utility is very similar to kill but uses a command name instead of a PID number. To kill all your processes that are running xeyes or vi, you can give the following command:

$ killall xeyes vi

When root gives this command, all processes that are running xeyes or vi on the system are killed.

The pidof utility displays the PID number of each process running the command you specify. Because this utility resides in /sbin, you must give the absolute pathname if you are not running as root:

$ /sbin/pidof httpd 567 566 565 564 563 562 561 560 553

If it is difficult to find the right process, try using top. Refer to the man pages for these utilities for more information, including lists of options.