Granting System Administrator Privileges to Regular Users

It may be necessary for regular users to run a command as if they were the root user. They usually do not need these powers, but they might on occasionfor example, to temporarily access certain devices or run a command for testing purposes.

There are two ways to run commands with root privileges: The first is useful if you are the super-user and the user; the second if you are not the regular user (as on a large, multiuser network).

Temporarily Changing User Identity with the su Command

What if you are also root, but are logged on as a regular user because you are performing nonadministrative tasks and you need to do something that only the super-user can do? The su command is available for this purpose.

Note

A popular misconception is that the su command is short for super-user; it just means substitute user. An important but often overlooked distinction is that between su and su -. In the former instance, you become that user but keep your own environmental variables (like paths). In the latter, you inherit the environment of that user. This is most noticeable when you use su to become the super-user, root. Without appending the -, you do not inherit the path variable that includes /bin or /sbin, so you must always enter the full path to those commands when you just su to root.

Because almost all Linux file system security revolves around file permissions, it can be useful to occasionally become a different user with permission to access files belonging to other users or groups or to access special files (such as the communications port /dev/ttyS0 when using a modem or the sound device /dev/audio when playing a game). You can use the su command to temporarily switch to another user identity, and then switch back.

Tip

It is never a good idea to use an Internet Relay Chat (IRC) client as the root user, and you might not want to run it using your regular user account. Simply create a special new user just for IRC and su to that user in a terminal widow to launch your IRC client.

The su command spawns a new shell, changing both the UID and GID of the existing user and automatically changes the environmental variables associated with that user, known as inheriting the environment. Refer to Chapter 5 for more information on environmental variables.

The syntax for the su command is

$ su option username arguments

The man page for su gives more details, but some highlights of the su command are

-c, --command COMMAND       pass a single COMMAND to the shell with -c -m, --preserve-environment       do not reset environment variables -l    a full login simulation for the substituted user,       the same as specifying the dash alone

You can invoke the su command in different ways that yield diverse results. By using su alone, you can become root, but you keep your regular user environment. This can be verified by using the printenv command before and after the change. Note that the working directory (you can execute pwd as a command line to print the current working directory) has not changed. By executing the following, you become root and inherit root's environment:

$ su -

By executing the following, you become that user and inherit the super-user's environmenta pretty handy tool. (Remember: Inheriting the environment comes from using the dash in the command; omit that, and you keep your "old" environment.) To become another user, specify a different user's name on the command line:

$ su - other_user

When leaving an identity to return to your usual user identity, use the exit command. For example, while logged on as a regular user,

$ su - root

the system prompts for a password:

Password:

When the password is entered correctly, the root user's prompt appears:

#

To return to the regular user's identity, just type

# exit

This takes you to the regular user's prompt:

$

If you need to allow other users access to certain commands with root privileges, it is necessary to give them the root password so that they can use suthat definitely is not a very secure solution. The next section describes a more flexible and secure method of allowing normal users to perform selected root tasks.

Granting Root Privileges on OccasionThe sudo Command

It is often necessary to delegate some of the authority that root wields on a system. For a large system, this makes sense because no single individual will always be available to perform super-user functions. The problem is that UNIX permissions come with an all-or-nothing authority. Enter sudo, an application that permits the assignment of one, several, or all of the root-only system commands.

After it is configured, using sudo is simple. An authorized user merely precedes the super-user- authority-needed command with the sudo command, like so

$ sudo command

After getting the user's password, sudo checks the /etc/sudoers file to see whether that user is authorized to execute that particular command; if so, sudo generates a "ticket" for a specific length of time that authorizes the use of that command. The user is then prompted for his password (to preserve accountability and provide some measure of security) and then the command is run as if root had issued it. During the life of the ticket, the command can be used again without a password prompt. If an unauthorized user attempts to execute a sudo command, a record of the unauthorized attempt is kept in the system log and a mail message is sent to the super-user.

Three man pages are associated with sudo: sudo, sudoers, and visudo. The first covers the command itself, the second the format of the /etc/sudoers file, and the third the use of the special editor for /etc/sudoers. You should use the special editing command because it will check the file for parse errors and lock the file to prevent others from editing it at the same time. The visudo command uses the vi editor, so you might need a quick review of the vi editing commands found in Chapter 5 in the section "Working with vi." You begin the editing by executing the visudo command with

# visudo

The default /etc/sudoers file looks like this:

# sudoers file. # # # This file MUST be edited with the 'visudo' command as root. # # See the sudoers man page for the details on how to write a sudoers file. # # Host alias specification # User alias specification # Cmnd alias specification # Defaults specification # User privilege specification root    ALL=(ALL) ALL # Uncomment to allow people in group wheel to run all commands # %wheel        ALL=(ALL)       ALL # Same thing without a password # %wheel        ALL=(ALL)       NOPASSWD: ALL # Samples # %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom # %users  localhost=/sbin/shutdown -h now

The basic format of a sudoers line in the file is

user host_computer=command

The user can be an individual user or a group (prepended by a % to identify the name as a group). The host_computer is normally ALL for all hosts on the network and localhost for the local machine, but the host computer can be referenced as a subnet of any specific host. The command in the sudoers line can be ALL, a list of specific commands, or a restriction on specific commands (formed by prepending a ! to the command). A number of options are available for use with the sudoers line, and aliases can be used to simplify the assignment of privileges. Again, the sudoers man page will give the details, but here are a few examples:

If we uncomment the line,

# %wheel    ALL=(ALL)    NOPASSWD: ALL

any user we add to the wheel group can execute any command without a password.

Suppose that we want to give user shelley permission across the network to be able to add users with the graphical interface. We would add the line

shelley ALL=/system-config-users

or perhaps grant permission only on her local computer:

shelley 192.168.1.87=/usr/bin/system-config-users

If we want to give the editor group systemwide permission with no password required to delete files,

%editors ALL=NOPASSWD: /bin/rm

If we want to give every user permission with no password required to mount the CD drive on the localhost,

ALL localhost=NOPASSWD:/sbin/mount /dev/scd0 /mnt/cdrom /sbin/umount /mnt/cdrom

It is also possible to use wildcards in the construction of the sudoers file. Aliases can be used as well to make it easier to define users and groups. Although the man page for sudoers contains some examples, http://www.komar.org/pres/sudo/toc.html provides illustrative notes and comments of sudo use at a large aerospace company. The sudo home page at http://www.sudo.ws/ is also a useful resource for additional explanations and examples.

The following command presents users with a list of the commands they are entitled to use:

$ sudo -l

Control Via Restricted Shells

Using restricted shells is actually the opposite of granting additional privileges to users. There might be situations in which you want to restrict a user to a very specific subset of privileges permitted to other users. If you have a desire to severely restrict what a user can do (for reasons of security, distribution of a turnkey system, or custom system installation), you can provide him with a restricted shell. To run a restricted bash shell, you would use the -r option. It is easy to try yourself, just enter the following at your prompt:

$ bash -r

Then try to do something that you could do before as a regular user, such as listing the files in your home directory:

$ ls -a

You then see

bash: ls: No such file or directory

The cd command, redirection, using / in command names, and several other commands and options are also disabled in the restricted shell. (The man page for bash details specific restrictions; the appropriate information is at the very end of the very long man page.) Do not rely on a restricted shell as your only means of controlling user activity; although using restricted shells applies some tight restrictions, a very determined user might find a way to confound the restrictions. Always use appropriate permission and password controls as well.