Sudo

sudo allows a permitted user to execute a command as the superuser or another user, as specified in the sudoers file. The real and effective uid and gid are set to match those of the target user as specified in the passwd file and the group vector is initialized based on the group file (unless the -P option was specified).

If the invoking user is root or if the target user is the same as the invoking user, no password is required. Otherwise, sudo requires that users authenticate themselves with a password by default.

Once a user has been authenticated, a timestamp is updated and the user may then use sudo without a password for a short period of time (5 minutes as default, unless overridden in sudoers).

After reading this guide you will know:

• The potential uses of sudo
• The dangers of sudo
• The dangers of misconfiguring sudo
• The basic structure of /etc/sudoers
• A little bit of what each section does
• A little more detail about the RunAs Specification section

The Basics

• app-admin/sudo allows a user to temporarily gain the privileges (and restrictions!) of another user (most commonly root). Having this possibility has many advantages:
  • The most obvious advantage: You don't have to log in as root just to shutdown your system.
  • If you have, say, three administrators on a server, you could of course just give everyone the root password. Instead, you can configure sudo so that each of the admins can execute only a small subset of all available commands via sudo, and for these commands, they only need their user password, rather than the root-password.
  • Single commands can be executed with higher privileges. Imagine a script that has several hundred commands, of which only one needs root privileges. You could of course execute the script as root, but instead, you could modify the script so that only the one command that actually needs these privileges is executed with these privileges.
• /etc/sudoers is the config-file for sudo. This file, however, cannot be edited with a normal editor such as app-editors/vim or app-editors/nano. This can only be done using the visudo command as root.
• For a complete reference of all options see man sudo and man sudoers.

Configuration

To start configuring sudo you must first become root

and then simply type

... which, on Gentoo, contains several nice examples. If you are looking for a simple configuration, skip to "RunAs Specification". The /etc/sudoers file consists of four sections. Likewise, each one of has it's own section in this wiki ;-):

• Alias Specification: Here you can specify aliases, i.e. to group certain commmands into one variable.
• Defaults: Here you can modify the default behaviour of sudo.
• Flags: Modify the behaviour of sudo even more.
• RunAs Specification: The most important section. Here you finally specify who is allowed to run what, where and as whom.

Alias Specification

If you have a system with multiple users, you can also specify aliases (a.k.a. variables) so you don't have to specify the same thing over and over again. You can do this for any part of the lines that actually specify who is allowed to run what (see below). For example, if you have several users that should each be allowed to do the same thing, you could write:

# User alias specification
User_Alias     FULLTIMERS = millert, mikef, dowdy

You can specify as many User_Alias lines as you need. You can also specify "Runas_Alias", "Host_Alias" or "Cmnd_Alias". The "RunAs Specification" section below will clear up what these alias mean and how they can be used.

Defaults

TODO (but not that important for basic usage)

Flags

TODO (but not that important for basic usage)

RunAs Specification

Arguably, the most important part of /etc/sudoers. For reference, here are some example lines, which don't make up a valid configuration:

# very simple, extremly insecure:
joe       ALL = (ALL) ALL
# more complex:
%wheel    dhcp_client = (root) NOPASSWD: /usr/bin/dhcpcd

• The first line specifies that the user joe may run any command, on any machine, as any user, but he must authenticate himself (therefore, must enter his own user password, not the root password!) since this is the default. Note: The default could, but should not, be overridden in the Defaults section above. Please note that this is a very insecure and dangerous thing to do.
• The second line is more complex. Every user in the group wheel is allowed to run /usr/bin/dhcpcd, but only as root and only on the machine "dhcp_client". The "NOPASSWD:" means that no password need be provided at all.

Remember the above chapter about Aliases? Now we want all "Fulltimers" to be able to execute commands in /sbin as either "mat" or "joe" and only on the machine "webserver". This would also allow them to reinstall another bootloader or format a disk, and we don't want the fulltimers to be able to do that. For completeness, the Alias Specification is also listed here:

# User_Alias Specification, here, all the fulltimers
User_Alias     FULLTIMERS = millert, mikef, dowdy
User_Alias     MAT_OR_JOE = mat, joe

# an Alias for the commands the Fulltimers should be allowed to use
Cmnd_Alias     COMMANDS = /sbin/*, !/sbin/lilo, !/sbin/mk*

# the actual RunAs Specification:
FULLTIMERS     webserver = (MAT_OR_JOE) COMMANDS

The "!" excludes certain commands and the "*" is a general wildcard. Sudo allows some sort of wildcards and can use a regular-expression like syntax. Please refer in man sudoers to the section Wildcards. The above specification seems like a good idea at first, but it is not. Imagine millert is doing this (assuming millert is also allowed to do a cp command with sudo):

millert@webserver $ sudo cp /sbin/lilo /sbin/this_is_not_a_bootloader
millert@webserver $ sudo /sbin/this_is_not_a_bootloader

Wuhu, and already millert is able to destroy the bootloader: /sbin/this_is_not_a_bootloader is not listed as a forbidden command (which would only be lilo or anything starting with "mk"). sudo will simply allow him to execute that. Another way to get around the above restrictions is to install another bootloader (just "emerge grub", if the user is allowed to use the emerge command).

Another very bad idea is to allow someone to execute a shell as root. If you do sudo /bin/bash all of a sudden you have a root-shell which allows you to do everything, including change the sudoers file. Worst of all, none of the commands run in the root-shell will be logged. The log-file of sudo still tells you that someone obtained a root shell, but everything that happened after that is up to your guess.

So generally, it is a bad idea to give a general list of commands (such as "ALL" or "/sbin") and then exclude the dangerous ones. It is safer to list the commands the user actually needs. Of course, it is also possible to specify multiple Cmnd_Alias and use them in one RunAs Specification:

Cmnd_Alias     HALT_AND_REBOOT = /usr/bin/halt, /usr/bin/reboot
Cmnd_Alias     REBOOT = /usr/bin/reboot

joe     webserver = (root) HALT_AND_REBOOT, !REBOOT

This may not be useful in reality (it would be more simple to specify "HALT" as Cmnd_Alias), but it shows an important point: the config-file is parsed in a single pass. The order of what you write is important. Therefore, exchanging the two Cmnd_Alias would not mean the same.

Using sudo

Autocompletion with sudo

If you are not using the programmable completion in bash you can add the following line in your ~/.bashrc:

complete -cf sudo

If you are using programmable completion you should adjust your settings in your bash_completion file, otherwise this will overwrite your settings for sudo.

Using gksu or kdesu with sudo

As sudo cleans the environment by default it's not possible to run graphical programs with root privileges, using gksu + sudo. To make X apps run correctly using gksu (or kdesu), you should export some environment variable in the sudo environment. In the sudoers file add:

Defaults env_keep="DISPLAY XAUTHORITY"

This section could also include

• usefull commands to be able to execute on a simple single user system
• Setting up a bash-alias via .bash_rc
• Editing a script so it can be run as normal user
• Please fill out the above or post other things

To make kdesu use sudo as backend instead of su follow kdesu.

Troubleshooting

gksu claims incorrect password

If gksu repeatedly claims that you do not have the correct password, you might need to ensure that your 'su' program is setuid.

chmod u+rws,go+x /bin/su