System Administrator and Superuser

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 sudo (page 431) 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. On an OS X Server system, the root account initially has the same password as the first user. On a non-Server system, the root account is disabled 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 (#). In graphical applications, such as System Preferences, root privileges are generally denoted by a lock icon. If the lock is open, you have root privileges. When you click a closed lock, the system prompts you for a username and password. When you enter the username and password for root or for an administrative user (a member of the admin group), the lock icon opens and you have root privileges.

Security: Change the root password

On an OS X Server system, the root account starts with the same password as the first account that was created on the system. It is a good idea to change this password to help prevent users from making unwanted changes to the system. Because users with administrative accounts can use sudo (page 431) to obtain root privileges, changing the root password does not offer complete protection against attacks, but it is a step in the right direction.

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 sudo so that you have root privileges, do as much of the task as 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 437), you are Superuser.
Once the system is up and running in multiuser mode (page 438), if you have enabled the root account, you can log in as root. When you supply the proper password, you will be running as Superuser.
You can give an su (substitute user) command while you are logged in as yourself and, with the proper password, will have Superuser privileges. For more information refer to "su: Gives You Another User's Privileges" on page 430.
You can use sudo selectively to give users Superuser privileges for a limited amount of time on a per-user and per-command basis. See page 431 for more information on sudo.
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. Your site should have as few of these programs as necessary.
Any user can create a setuid (set user ID) file (page 90). Setuid programs run on behalf of the owner of the file and have all of the owner's access privileges. 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 are restored to the way they were before the program was started. Setuid programs that are owned by root are extremely powerful and extremely dangerous to system security, which is why very few of them are on the system. Examples of setuid programs that are owned by root include passwd, at, and crontab. The following example shows two ways for a user to give a program setuid privileges:
```
$ ls -l my* -rwxr-xr-x   1 zach zach 17000 Mar  2 02:31 myprog -rwxr-xr-x   1 zach zach 17000 Mar  2 02:31 myprog2 $ chmod 4755 myprog $ chmod u+s myprog2 $ ls -l my* -rwsr-xr-x   1 zach zach 17000 Mar  2 02:31 myprog -rwsr-xr-x   1 zach zach 17000 Mar  2 02:31 myprog2 
```
The s in the owner execute position of the ls l output (page 87) indicates that the file has setuid permission. Under Mac OS X 10.3.9 and later, the setuid permission bit is ignored on shell scripts.
Some programs ask you for a password when they start or when you perform a function that needs Superuser privileges. For graphical applications, you can provide the username and password of an administrative user. If you are an administrative user, the sudo utility (page 431) can give you Superuser privileges using your own password. When a program asks for a password to gain Superuser privileges, you stop running as the privileged user when you quit using the program. This setup helps keep you from remaining logged in as Superuser when you do not need or intend to be. Some techniques limit the number of ways in which you can become Superuser. PAM (page 466) controls the who, when, and how of logging in. The /etc/ttys file controls which terminals (ttys) a user can log in on as root.

Security: Do not allow root access over the Internet

If you need root access to a system over a network, use ssh (page 847) to connect to the system. The root account is not enabled by default, so you must connect as an ordinary user and then use sudo to gain root privileges. If you enable the root account, you should deny direct access to it through ssh. In the file /etc/sshd_config, add the line PermitRootLogin no.

Enabling the `root` Account

On an OS X Server system, the root account is enabled by default and has the same password as the first user created on the system. Initially on a non-Server system there is no password for root, so there is no way to log in as root or to use su to become root. However, you can use an sudo sh or sudo -s command to spawn a root shell (a shell with Superuser privileges).

If you are an administrative user (a member of the admin group, one with the Allow user to administer this computer checked in the Accounts preference pane), you can use the following command to enable the root account by assigning a password to it:

$ sudo passwd root Password: Changing password for root. New password: Retype new password:

Enter your password at the first prompt, then enter the new root password at the next two prompts. Once you have assigned a password to root, you must use this password when you log in as root and when you use su to become root temporarily.

System Maintenance Tools

Many tools can help you be an efficient and thorough system administrator. This section describes three powerful utilities: su, which allows you to take on the identity of another user; sudo, which performs the same basic function as su but is configurable; and kill, which, when run by root, allows you to terminate any process. See "Useful Utilities" on page 448 for brief descriptions of additional maintenance tools.

`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. Under OS X, a system administrator frequently uses sudo in place of su. Follow su on the command line with the name of a user; if you are root or if you know that 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 (root must have a password [see page 430] and 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 the local 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 to have you run a fake su command, you are in serious trouble anyway, but using an absolute pathname for su is still a good idea.)

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 first or last element of PATH. For more information refer to "PATH: Where the Shell Looks for Programs" on page 285.

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 only minimal changes to your environment. When you give the command su (you can use l 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.

Use the id utility to display the changes in your user and group IDs and in the groups you are associated with.

$ id uid=501(alex) gid=501(alex) groups=501(alex), 81(appserveradm), ... $ su Password: # id uid=0(root) gid=0(root) groups=0(wheel), 1(daemon), 2(kmem), ...

`sudo`: Performs Specific Tasks as Another User

The sudo utility offers a more flexible approach to using the privileges of another user. As a member of the admin group you can modify the /etc/sudoers file to configure the privileges offered by sudo. Unlike su, sudo uses your password to authenticate, not the password of the user whose privileges you want to use. Under OS X, any account in the admin group can use sudo to run any command as root, even if the root account has not been enabled (there is no root password). Give the command su l (lowercase "l," for list) to display the list of commands you are allowed to run with sudo.

The sudo utility takes its arguments as the command it is to run. The following example first shows that a user is not permitted to kill (page 432) a process. With the use of sudo and the user's password, an administrative user is permitted to kill the process.

$ kill -15 4982 -bash: kill: (4982) - Operation not permitted $ sudo kill -15 4982 Password: $

You can also use sudo to obtain a root shell by giving an argument of bash or by using the s option:

$ sudo -s Password: #

The sudo utility enables you to execute a command as a user other than root. The following command allows Max, who must be a member of the admin group, to list the contents of Sam's home directory while avoiding running a command as root:

$ ls ~sam ls: /Users/sam: Permission denied $ sudo -u sam ls ~sam src personal bin

When you have successfully run sudo within the last five minutes it does not ask for a password again. This courtesy reduces the temptation to start a root shell, possibly forgetting to exit from it.

`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 577 for a discussion of the various signals and the way a process receives them. Running kill is not the first method a user or system administrator should try when a process needs to be aborted.

Caution: kill: method of last resort

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

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

Usually a user can kill a process by working from 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 give you this information once you know the name of the program the user is running and/or the username of the user. The top utility (page 874) can also be helpful in finding and killing a runaway process (see top's S command).

In the following example, Zach complains that Safari is stuck and that he cannot do anything from the Safari window, not even close it. A more experienced user could open another window and kill the process or use the Force Quit option on the Apple menu. In this case, you kill it for Zach. First use ps with the U option, followed by the name of the user, to view all processes associated with that user:

$ ps -U zach   PID  TT  STAT     TIME COMMAND   133  ??  Ss    0:03.92 /System/Library/Frameworks/ApplicationServices.framew 14191  ??  Ss    0:01.18 /System/Library/CoreServices/loginwindow.app/Contents 14203  ??  Ss    0:00.43 /System/Library/CoreServices/pbs 14210  ??  S     0:00.96 /System/Library/CoreServices/Dock.app/Contents/MacOS/ 14211  ??  S     0:01.99 /System/Library/CoreServices/SystemUIServer.app/Conte 14212  ??  S     0:01.26 /System/Library/CoreServices/Finder.app/Contents/MacO 14220  ??  S     0:00.17 /usr/sbin/sshd -i 14247  ??  S     0:04.86 /Applications/Safari.app/Contents/MacOS/Safari -psn_0 14222  p1  Ss    0:00.08 -bash

This list is fairly short, and the process running Safari is easy to find. If the list is long, you can use grep with the i option (for a search that is not case sensitive) to find the process running Safari:

$ ps -U zach | grep -i safari 14247  ??  S      0:04.87 /Applications/Safari.app/Contents/MacOS/Safari -psn_0

Now that you know the PID of Zach's process running Safari is 14247, you can use kill to terminate it. The safest way to use kill is to log in as Zach (perhaps allow him to log in for you or su to zach [su zach] if you are logged in as root) and give the command

$ kill TERM 14247

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

$ kill KILL 14247

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 than when you make the same mistake while you are logged in as an ordinary user. A user can kill only his own processes, whereas Superuser can kill any process, including system processes. (There are a few exceptions: You may be temporarily unable to kill a process waiting on disk activity, and the launchd or init process with PID 1 cannot be killed.)

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 Zach:

# su zach -c "kill -TERM 14247"

killall

A useful utility related to kill is killall. It is very similar to kill but uses a command name in place of a PID number. To kill all your processes that are running iTunes or vim, you can give the following command:

$ killall iTunes vim

When given by root, this command kills all processes running iTunes or vim.

You can also list processes and send signals using the Activity Monitor application (found in the Utilities folder within Applications).

Avoiding a Trojan Horse

A Trojan horse is a program that does something destructive or disruptive to your system while appearing to be benign. As an example, you could store the following script in an executable file named ifconfig:

while true     do     echo 'Good Morning Mr. Jones. How are you? Ha Ha Ha.' > /dev/console     done

If you are running as Superuser when you run this command, it would continuously write a message to the console. If the programmer were malicious, it could do worse. The only thing missing in this plot is access permissions.

A malicious user could implement this Trojan horse by changing Superuser's PATH variable to include a publicly writable directory at the start of the PATH string. (The catch is that you need to write to /etc/profilewhere the PATH variable is set for rootand only root can do that.) Then you would need to put the bogus ifconfig program file in that directory. Because the fraudulent version appears in a directory mentioned earlier than the real one in PATH, the shell runs it. The next time Superuser tries to run ifconfig, the fraudulent version would run instead of the system version.

Trojan horses that wait for and take advantage of the misspellings that most people make are among the most insidious types. For example, you might type sl instead of ls. Because you do not regularly execute a utility named sl and you may not remember typing the command sl, it is more difficult to track down this type of Trojan horse than one that takes the name of a more familiar utility.

A good way to help prevent the execution of a Trojan horse is to make sure that your PATH variable does not contain a single colon (:) at the beginning or end of the PATH string or a period (.) or double colon (::) anywhere in the PATH string. This precaution ensures that you will not execute a file in the working directory by accident. A common way to check for a possible Trojan horse is to examine the filesystem periodically for files with setuid (refer to item 5 on page 429). The following command lists these files:

# find / -perm -4000 -exec ls -lh {} \; 2> /dev/null rwsrwsr-x    1 root  admin    30K Feb 14 03:19 /Applications/Server/AppleSha<...> rwsrwxr-x    1 root  wheel    17K Feb 14 03:25 /Applications/System Preferen<...> rwsrwxr-x    1 root  admin    52K Feb 14 03:13 /Applications/Utilities/Activ<...> ... -rwsr-xr-x   1 root  wheel    31K Feb 13 21:03 /bin/ps -r-sr-xr-x   1 root  wheel    24K Feb  7 04:05 /bin/rcp -rwsr-xr-x   1 root  wheel    69K Feb 14 03:38 /sbin/launchd -r-sr-xr-x   1 root  wheel    19K Feb 13 20:56 /sbin/mount_nfs -r-sr-xr-x   1 root  wheel    322K Feb 14 03:29 /sbin/mount_smbfs -r-sr-xr-x   1 root  wheel    32K Feb  7 04:05 /sbin/ping -r-sr-xr-x   1 root  wheel    41K Feb  7 04:09 /sbin/ping6 -r-sr-sr-x   2 root  tty    73K Feb 13 20:57 /sbin/restore -r-sr-xr-x   1 root  wheel    33K Feb  7 04:05 /sbin/route -r-sr-sr-x   2 root  tty    73K Feb 13 20:57 /sbin/rrestore ...

This command uses find (page 728) to locate all files that have their setuid bit set (mode 4000). For more information refer to "Access Permissions" on page 87. The hyphen preceding the mode causes find to report on any file that has this bit set, regardless of how the other bits are set. The output sent to standard error is redirected to /dev/null (page 444) so that it does not clutter the screen.

Getting Help

Mac OS X comes with extensive documentation (page 27). Apple maintains a Web page that points to many useful support documents: www.apple.com/support. You can also find help on the System Administrator's Guild site (www.sage.org). In addition, the Internet is a rich source of information on managing a UNIX system of any sort; refer to Appendix B (page 907) and to the author's home page (www.sobell.com) for pointers to useful sites.

You do not need to act as a Mac OS X system administrator in isolation; a large community of OS X experts is willing to assist you in getting the most out of your system, although you will get better help if you have already tried to solve a problem yourself by reading the available documentation. If you are unable to solve a problem by reviewing the documentation, a well-thought-out question to the appropriate newsgroup, such as comp.sys.mac.system, or mailing list can often provide useful information. Make sure you describe the problem and identify your system carefully. Include information about your version of OS X and any software packages and hardware that might relate to the problem. For a good paper by Eric S. Raymond and Rick Moen titled "How to Ask Questions the Smart Way" see www.catb.org/~esr/faqs/smart-questions.html.

Enabling the root Account