Using the root account for day-to-day work is a bad idea. It's better to use sudo to act like root when you need to do a little system administration. Ken Hess shows you how.
A Linux system has two kinds of users: ordinary users and the root user. Each ordinary user has a robust set of permissions to manage his or her own files (and files that belong to a group that he or she is a member of), but an ordinary user cannot affect system configuration, start or stop essential services such as the SSH daemon, and cannot reserve a so-called privileged port, or any networking port numbered less than 1,024. The root user, though, is free to access and modify any file, perform any task, and affect the system at will.
Of course, as Spider-Man says, ‘With great power comes great responsibility.’ root must be cautious, because a small typo can lead to disaster. For example, there’s a big difference between the command
rm -rf /a and
rm -rf /. Given the potential for such accidental cataclysms, it’s considered a best practice to never log in as root, lest you forget or misdirect the (remaining in the Marvel Comics universe) Thor-like power you wield.
Indeed, many Linux distributions preclude root logins, preferring instead to grant the initial user the right to act like root when necessary. This special privilege, which can be extended to other users on the system, is managed via the
sudo (pronounced ‘soodoo’) utility.
sudo controls who can act like root, and can further control what a user can do as root.
When a task requires root powers, and assuming the user has the right to perform the task at hand as root, the user simply prefaces the command with
sudo. For example, say the /tmp directory is filled with oodles of scratch files created by a myriad of users. While each user can only remove his or her own scratch files, a user with the right to run
rm as root (as dictated by
sudo) can clean the entire directory with one command:
$ sudo rm -rf /tmp/*
The user khess has limited rights. However, prefacing the command with
sudo invokes the command as if the user was root. Yes, you can still make a typo and remove all of /tmp, but
sudo minimizes the use of root privileges and hence the risk of mistakes.
So su Me
sudo is something of a specialized version of another ‘alter ago’ application named
su, short for ‘substitute user.’
su allows one user to temporarily act like another. Specifically,
su runs a shell with substitute user and group IDs. Any user may issue /bin/su and switch to any other user account, including root, if the substituted user’s password is known.
$ su - bob
- option starts a login shell as the user bob. Once you type Bob’s password at the prompt, you are bob. Every file you create or process you start is owned by Bob. If you
exit the login shell spawned by
su, your original user and group IDs are restored, as shown above.
su can also be used to become root just as it’s used to become bob, or any other user.
$ su -
Assuming you know the root password,
su - (the username is omitted) changes your user and group ID to root.
However, disseminating root’s password isn’t recommended because it poses a serious security risk. If the password fell into the hands of a malcontent, the system (or many systems) could be compromised.
To enhance the security of
su, change the permissions of /bin/su to allow only root and group admin access:
# chgrp admin /bin/su
# chmod o-rwx /bin/su
# ls -l /bin/su
r-sr-x--- root admin '
Here, read and execute rights have been rescinded for ‘other’, and the group owner has been changed to limit access to the members of the admin group. This is the recommended setup for a multiuser system.
Who Do You sudo?
su is restricted, it’s use still requires the root password. A leaked password is one risk, but changing the root password frequently may also lead to problems, as passwords, especially well-constructed cyphers, are difficult to remember.
sudo was invented to solve these two issues and more.
sudo catalogs who can become root and what the user can run as root. The catalog is maintained in /etc/sudoers.
To determine if you have
sudo privileges, run the command
$ sudo -l
Here, you must enter your password to authenticate yourself, preventing a miscreant from abusing your privileges. If you do not have
sudo access, you’ll receive a message similar to:
Sorry, user fred may not run sudo on this host
sudo presents the list of commands that you have rights to execute:
$ sudo -l
User fred may run the following commands on this host:
As you can see, fred can control the Apache HTTP Server daemon via
apachectl as root.
After you invoke
sudo and provide your password,
sudo provides a ‘ticket’ good for five minutes of access. During these five minutes, you need not provide your password again to run additional commands via
In fact, each command you execute within five minutes extends the five-minute window. However, if you fail to issue any command using
sudo within five minutes, the ticket expires and you must re-authenticate to re-use
sudo. A timeout precludes others from usurping your privileges while you’re out to lunch or otherwise away from the computer.
Here’s an example of a series of
sudo commands to copy and edit a file and restart Apache:
$ sudo cp -p index.html index.html.20070511
$ sudo vi index.html
$ sudo apachectl restart
You must prepend each command with
sudo. If you don’t prepend the command with
sudo, the system assumes you are issuing the command as yourself.
How Do You
As shown above,
sudo need not be the key to Pandora’s Box. A user can be restricted to run a collection of commands. fred, for instance, can stop, start, and restart Apache via
apachectl, but cannot run
To edit the
sudo catalog, /etc/sudoers you must use a special editor named
visudo. The catalog has a somewhat complex and specific format. Listing One is an example sudoers file.
Listing One: A sample /etc/sudoers file
# User privilege specification
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL
strike ALL=(ALL) NOPASSWD:ALL
# Uncomment to allow people in group wheel to run all commands
%wheel ALL=(ALL) ALL
The first field is either a user name, such as
strike, or a group name, such as
The second field specifies a list of hosts. (Since the same sudoers file may be copied to all machines on the network for consistency, you may allow different privileges on different hosts.) The abbreviation
ALL matches any hostname.
The third field (the one in parentheses following the
=) enumerates usernames or IDs. A command can run as any of the listed users. This is valuable when you need to stop, start, restart, kill a process that isn’t owned by root. (Of course, you can kill any process as root, but you may not want to start any process as root, inadvertently giving a simple service root privileges.) Again,
ALL matches any user.
The fourth field lists the commands that can be run.
Or, put more simply, the fields are:
Username Hosts=(Usernames or UIDs)) Commands
Separate multiple entries for any of the latter fields with commas. (You can refer to the
sudoers man page for details.)
Hence, this user privilege specification:
root ALL=(ALL) ALL
allows the root user to run all commands on all hosts as any user. Similarly, if you’re fred and use a desktop Linux system, /etc/sudoers probably contains an entry like this:
fred ALL=(ALL) ALL
This is reflected by
$ sudo -l
User fred may run the following commands on this host:
To run a command as a user other than root (assuming sudoers permits it), use the
$ sudo -u nobody /etc/init.d/some_service restart
This restarts some service as the user nobody. To issue more than one command as another user, the switch must be used each time you invoke
sudo. If you omit
-u, root is assumed.
Sudo’s and Sudon’ts
Here’s a list of things to do and to avoid when you setup and use
Specify the full path to all commands for aliases and single commands.
Use aliases for hosts, groups, and commands. (See the
man page to create aliases.)
Follow the principle of ‘least privilege’: Only grants those rights that are needed and nothing more, and be explicit.
Check the log files /var/log/auth.log or /var/log/secure often for
sudo usage and violations.
Don’t try to exclude commands from
ALL. (Again, use aliases.)
ALL=(ALL) ALL to anyone.
Do not specify the
NOPASSWD modifier for regular users.
NOPASSWD allows a user to use
sudo without password authentication.
Sudo You Think You’re Foolin’?
A great many problems can be solved by using
sudo. Best of all, you don’t have to give the root password to anyone other than administrators or the system owner. Clever use of
sudo can track privileged use on a system.
sudo can also create exploits if you allow users too much access. For example, if you permit a user to have access to
ALL, the user can become root permanently (until their next login, anyway) using the command
sudo su - or
sudo /bin/bash. Implementing
sudo policies should be a well- thought out undertaking.
sudo can either bring much comfort to nervous administrators or much heartache to cavalier ones.
Kenneth Hess is a Linux evangelist and freelance technical writer on a variety of open source topics including Linux, SQL, databases, and web services. Ken can be reached via his website at http://www.kenhess.com
. Practical Virtualization Solutions by Kenneth Hess and Amy Newman is available now.