Gentoo Wiki


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.

Note: The default configuration uses the user's password, not the root password. That's the whole point of sudo; users can execute some commands but don't know the root password

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).

Warning: Sudo is a very powerful tool that can be used in many ways, including the wrong way. Be very careful when you configure sudo!

After reading this guide you will know:


The Basics


Note: (At least as of now) this guide does not even attempt to cover the more complex and powerful configuration details of sudo.

To start configuring sudo you must first become root

Code: Become root


and then simply type

Code: edit /etc/sudoers


... 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 ;-):

Note: In order to keep the config file as clear as possible, I highly advise that you write the config file in the following way:
  • First, write a comment (a line that starts with a '#') where you specify exactly what you want that line to do
  • THEN write the line that is supposed to do the above thing.
  • Go over that line again. Could it mean more then it is supposed to? Which rights exactly does this line grant to whom?
  • Try to think of ways to use that rule to do something different or of ways to circumvent the restrictions imposed by it or other rules (examples are also given further on).

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:

Code: User alias specification (from 'man sudoers')
# 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.


TODO (but not that important for basic usage)


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:

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

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:

Code: Another Example
# 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:

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

Code: How-To use lilo as millert
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:

Code: multiple Cmnd_Alias
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.

Note: The man page clearly says the above sentence is true, but I have not tested it. Could someone do that?

Using sudo

Autocompletion with sudo

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

Code: completion with sudo
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

Warning: This approach will lower the security level of your system. If you don't trust all your users you should use gksu with su, as in the default config.

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:

Code: X apps with sudo
Defaults env_keep="DISPLAY XAUTHORITY"

This section could also include

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


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.

Code: Make /bin/su setuid
chmod u+rws,go+x /bin/su
Retrieved from ""

Last modified: Fri, 12 Sep 2008 19:51:00 +0000 Hits: 14,425