2 sudo basics #

As a regular user, you can run any command as root by adding sudo before it. This prompts you to provide the root password. If authenticated successfully, this runs the command as root:

> id -un1
tux
> sudo id -un
root's password:2
root
> id -un
tux3
> sudo id -un
4
root

Tip: I/O redirection

When using sudo, I/O redirection does not work:

> sudo echo s > /proc/sysrq-trigger
bash: /proc/sysrq-trigger: Permission denied
> sudo cat < /proc/1/maps
bash: /proc/1/maps: Permission denied

In the example above, only the echo and cat commands run with elevated privileges. The redirection is done by the user's shell with user privileges. To perform redirection with elevated privileges, either start a shell as in Section 2.1.2, “Starting a shell” or use the dd utility:

echo s | sudo dd of=/proc/sysrq-trigger
sudo dd if=/proc/1/maps | cat

Using sudo every time to run a command with elevated privileges is not always practical. While you can use the sudo bash command, it is recommended to use one of the built-in mechanisms to start a shell:

Tip: Environment variables

By default, sudo does not propagate environment variables. This behavior can be changed using the env_reset option (see Useful flags and options).

The main policy configuration file for sudo is /etc/sudoers. As it is possible to lock yourself out of the system if the file is malformed, it is strongly recommended to use visudo for editing. It prevents editing conflicts and checks for syntax errors before saving the modifications.

You can use another editor instead of vi by setting the EDITOR environment variable, for example:

sudo EDITOR=/usr/bin/nano visudo

Keep in mind that the /etc/sudoers file is supplied by the system packages, and modifications done directly in the file may break updates. Therefore, it is recommended to put custom configuration into files in the /etc/sudoers.d/ directory. Use the following command to create or edit a file:

sudo visudo -f /etc/sudoers.d/NAME

The command bellow opens the file using a different editor (in this case, nano):

sudo EDITOR=/usr/bin/nano visudo -f /etc/sudoers.d/NAME

Note: Ignored files in /etc/sudoers.d

The #includedir directive in /etc/sudoers ignores files that end with the ~ (tilde) character or contain the . (dot) character.

For more information on the visudo command, run man 8 visudo.

The sudoers configuration files contain two types of options: strings and flags. While strings can contain any value, flags can be turned either ON or OFF. The most important syntax constructs for sudoers configuration files are as follows:

# Everything on a line after # is ignored 1
Defaults !insults # Disable the insults flag 2
Defaults env_keep += "DISPLAY HOME" # Add DISPLAY and HOME to env_keep
tux ALL = NOPASSWD: /usr/bin/frobnicate, PASSWD: /usr/bin/journalctl 3

The Defaults token can also be used to create aliases for a collection of users, hosts, and commands. Furthermore, it is possible to apply an option only to a specific set of users.

For detailed information about the /etc/sudoers configuration file, consult man 5 sudoers.

Each rule follows the following scheme ([] marks optional parts):

#Who      Where         As whom      Tag                What
User_List Host_List = [(User_List)] [NOPASSWD:|PASSWD:] Cmnd_List

ALL can be used as User_List, Host_List, and Cmnd_List.

A rule that allows tux to run all commands as root without entering a password:

tux ALL = NOPASSWD: ALL

A rule that allows tux to run systemctl restart apache2:

tux ALL = /usr/bin/systemctl restart apache2

A rule that allows tux to run wall as admin with no arguments:

tux ALL = (admin) /usr/bin/wall ""

Warning: Unsafe rules

Do not use rules like ALL ALL = ALL without Defaults targetpw. Otherwise anyone can run commands as root.

By design, members of the group wheel can run all commands with sudo as root. The following procedure explains how to add a user account to the wheel group.

Starting graphical applications with sudo usually results in the following error:

> sudo xterm
xterm: Xt error: Can't open display: %s
xterm: DISPLAY is not set

A simple workaround is to use xhost to temporarily allow the root user to access the local user's X session. This is done using the following command:

xhost si:localuser:root

The command below removes the granted access:

xhost -si:localuser:root

Warning: Potential security issue

Running graphical applications with root privileges has security implications. It is recommended to enable root access for a graphical application only as an exception. It is also recommended to revoke the granted root access as soon as the graphical application is closed.