From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Sudo and the translation is 29% complete.

Outdated translations are marked like this.
This article has been flagged as dirty for not conforming to the wiki guidelines. It is now grouped in the list of articles to be cleaned.
Other languages:
English • ‎español • ‎français • ‎italiano • ‎русский • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어

Warning: Display title "sudo/fr" overrides earlier display title "Sudo".


La commande sudo procure un moyen sûr et simple de configurer une escalade de privilèges, par exemple, permettre à des utilisateurs normaux d'exécuter certaines (ou toutes les) commandes en tant que root ou au nom d'un autre utilisateur, sans qu'ils aient à connaître le mot de passe de l'utilisateur auquel ils se substituent.

Lorsque vous voulez que certaines personnes accomplissent certaines tâches administratives sans leur donner un accès total en tant que root, utiliser sudo est la meilleure option. En effet, sudo permet de contrôler qui peut faire quoi. Ce guide est une petite introduction à ce puissant outil.

Cet article est une rapide introduction. Le paquet app-admin/sudo est bien plus puissant que ce qui est décrit ici. Il a des options supplémentaires permettant l'édition de fichier en tant qu'autre utilisateur (sudoedit), s'exécuter depuis un script (donc reste en arrière-plan, lit le mot de passe depuis l'entrée standard et non depuis le clavier,…), etc.

Merci de lire les pages de manuel de sudo et de sudoers pour plus d'informations.


Options de la variable USE

USE flags for app-admin/sudo Allows users or groups to run commands as other users

gcrypt Use SHA2 from dev-libs/libgcrypt instead of sudo's internal SHA2 local
ldap Add LDAP support (Lightweight Directory Access Protocol) global
offensive Let sudo print insults when the user types the wrong password local
openssl Use SHA2 from dev-libs/openssl instead of sudo's internal SHA2 local
sendmail Allow sudo to send emails with sendmail local
skey Enable S/Key (Single use password) authentication support global


root #emerge --ask app-admin/sudo



One additional advantage of sudo is that it can log any attempt (successful or not) to run an application. This is very useful if you want to track who made that one fatal mistake that took you 10 hours to fix :)

Accorder des autorisations

Le paquet app-admin/sudo permet à l'administrateur système d'autoriser certains utilisateurs à exécuter des applications auxquelles ils n'ont normalement pas accès. À la différence de setuid, sudo permet un contrôle plus fin de qui peut exécuter une certaine commande, et quand.

With sudo you can make a clear list of who can execute a certain application. If you set the setuid bit on an executable, any user would be able to run the application (or any user of a certain group, depending on the permissions used). With sudo you can (and probably should) require the user to provide a password in order to execute the application.

The sudo configuration is managed by the /etc/sudoers file. This file should never be edited through nano /etc/sudoers or vim /etc/sudoers, or any other editor you would normally use. When you want to alter the /etc/sudoers file, you should always use visudo. This tool makes sure that no two system administrators are editing this file at the same time, preserves the permissions on the file, and performs some syntax checking to make sure you make no fatal mistakes in the file.

Syntaxe de base

The most difficult part of sudo is the /etc/sudoers syntax. The basic syntax is as follows:

CODE Basic /etc/sudoers syntax
user  host = command

This line tells sudo that the user, identified by user and logged in on the system host, can execute the command command (which can also be a comma-separated list of allowed commands).

A more real-life example might make this more clear: To allow the user larry to execute emerge when he is logged in on localhost:

CODE Real /etc/sudoers example
larry  localhost = /usr/bin/emerge
The hostname must match the name that the hostname command returns.
In the simplest case, commands must be fully qualified paths to executables: hence /usr/bin/emerge not just emerge. Paths can also contain wildcards and may refer to entire directories. See the manpage for details.
Do not allow a normal user to run an application that can enable them to elevate privileges. For instance, allowing users to execute emerge as root can grant them full root access to the system because emerge can be manipulated to change the live file system to the user's advantage. If you do not trust your sudo users, don't grant them any additional rights.

The user name can also be substituted with a group name, in which case the name is prefaced by a % sign. For instance, to allow any one in the wheel group to execute emerge:

CODE Allowing any wheel group member to execute emerge
%wheel  localhost = /usr/bin/emerge

To enable more than one command for a given user on a given machine, multiple commands can be listed on the same line. For instance, to allow larry to not only run emerge but also ebuild and emerge-webrsync as root:

CODE Multiple commands
larry  localhost = /usr/bin/emerge, /usr/bin/ebuild, /usr/sbin/emerge-webrsync

You can also specify a precise command line (including parameters and arguments) not just the name of the executable. This is useful to restrict the use of a certain tool to a specified set of command options. The sudo tool allows shell-style wildcards (AKA meta or glob characters) to be used in path names as well as command-line arguments in the sudoers file. Note that these are not regular expressions.

Here is an example of sudo from the perspective of a first-time user of the tool who has been granted access to the full power of emerge:

user $sudo emerge -uDN world
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.
Password: ## (Enter the user password, not root!)

The password that sudo requires is the user's own password. This is to make sure that no terminal that you accidentally left open to others is abused for malicious purposes.

sudo does not alter the ${PATH} variable: any command placed after sudo is executed within the user's own environment. Thus if a user wants to run a tool in /sbin, for instance, the user must provide sudo with the full path of the command, like so:
user $sudo /usr/sbin/emerge-webrsync

Syntaxe de base avec LDAP

The ldap and pam USE flags are needed for the LDAP support.

Lorsque vous utilisez sudo avec LDAP, sudo lira la configuration depuis le serveur LDAP Server également. C'est pourquoi vous devez éditer deux fichiers.

FILE /etc/ldap.conf.sudoPlease chmod 400 when done
# See ldap.conf(5) and README.LDAP for details
# This file should only be readable by root
# supported directives: host, port, ssl, ldap_version
# uri, binddn, bindpw, sudoers_base, sudoers_debug
# tls_{checkpeer,cacertfile,cacertdir,randfile,ciphers,cert,key}
port 389
base dc=example,dc=com
uri ldap://
#uri ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock
ldap_version 3
#ssl start_tls
sudoers_base ou=SUDOers,dc=example,dc=com
#sudoers_debug 2
bind_policy soft
FILE /etc/nsswitch.confPlease add the sudoers line
sudoers:     ldap files

Vous devez aussi ajouter l'entrée LDAP suivante pour sudo.

Il a été conçu pour que la branche des sudoers soit au sommet de l'arbre pour des raisons de sécurité. Vous pouvez donc avoir des droits d'accès différents de ldap pour lire/écrire dans cette branche
CODE Ldap Entry for Sudo
version: 1
DN: ou=SUDOers,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
objectClass: domainRelatedObject
ou: SUDOers
DN: cn=defaults,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here
sudoOption: env_reset
DN: cn=root,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: root
sudoCommand: ALL
sudoHost: ALL
sudoUser: root
DN: cn=%wheel,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: %wheel
sudoCommand: ALL
sudoHost: ALL
sudoOption: !authenticate
sudoUser: %wheel
CODE Ldap Entry for wheel Group
version: 1
DN: cn=wheel,ou=Group,dc=example,dc=com
objectClass: top
objectClass: posixGroup
cn: wheel
description: Wheel Group
gidNumber: 10
memberUid: useradmin1
memberUid: root

La configuration des sudoer sur LDAP est similaire à celles des fichiers avec quelques différences. Lisez à propos de sudo avec LDAP à partir du lien ci-dessous .[1]

Utiliser des alias

In larger environments having to enter all users over and over again (or hosts, or commands) can be a daunting task. To ease the administration of /etc/sudoers you can define aliases. The format to declare aliases is quite simple:

CODE Declaring aliases in /etc/sudoers
Host_Alias hostalias = hostname1, hostname2, ...
User_Alias useralias = user1, user2, ...
Cmnd_Alias cmndalias = command1, command2, ...

Un alias qui marche toujours, pour toute position, est l'alias ALL (pour faire une distinction claire entre ce qui est un alias et ce qui ne l'est pas, il est recommandé d'utiliser des lettres capitales dans les alias). Comme vous l'avez sans doute déduit, l'alias ALL est un alias représentant tout ce qui est possible en matière de réglage.

A sample use of the ALL alias to allow any user to execute the shutdown command if he is logged on locally is:

CODE Allowing any user to execute shutdown
ALL  localhost = /sbin/shutdown

Another example is to allow the user larry to execute the emerge command as root, regardless of where he is logged in from:

CODE Allowing a user to run an application regardless of his location
larry   ALL = /usr/bin/emerge

More interesting is to define a set of users who can run software administrative applications (such as emerge and ebuild) on the system and a group of administrators who can change the password of any user, except root!

CODE Using aliases for users and commands
User_Alias  SOFTWAREMAINTAINERS = larry, john, danny
User_Alias  PASSWORDMAINTAINERS = larry, sysop
Cmnd_Alias  SOFTWARECOMMANDS    = /usr/bin/emerge, /usr/bin/ebuild
Cmnd_Alias  PASSWORDCOMMANDS    = /usr/bin/passwd [a-zA-Z0-9_-]*, !/usr/bin/passwd root

Non-root execution

It is also possible to have a user run an application as a different, non-root user. This can be very interesting if you run applications as a different user (for instance apache for the web server) and want to allow certain users to perform administrative steps as that user (like killing zombie processes).

Inside /etc/sudoers you list the user(s) in between ( and ) before the command listing:

CODE Non-root execution syntax
users  hosts = (run-as) commands

For instance, to allow larry to run the kill tool as the apache or gorg user:

CODE Non-root execution example
Cmnd_Alias KILL = /bin/kill, /usr/bin/pkill
larry   ALL = (apache, gorg) KILL

With this set, the user can run sudo -u to select the user he wants to run the application as:

user $sudo -u apache pkill apache

You can set an alias for the user to run an application as using the Runas_Alias directive. Its use is identical to the other _Alias directives we have seen before.

Passwords and default settings

By default, sudo asks the user to identify himself using his own password. Once a password is entered, sudo remembers it for 5 minutes, allowing the user to focus on his tasks and not repeatedly re-entering his password.

Of course, this behavior can be changed: you can set the Defaults: directive in /etc/sudoers to change the default behavior for a user.

For instance, to change the default 5 minutes to 0 (never remember):

CODE Changing the timeout value
Defaults:larry  timestamp_timeout=0

A setting of -1 would remember the password indefinitely (until the system reboots).

A different setting would be to require the password of the user that the command should be run as and not the users' personal password. This is accomplished using runaspw. In the following example we also set the number of retries (how many times the user can re-enter a password before sudo fails) to 2 instead of the default 3:

CODE Requiring the root password instead of the user's password
Defaults:john   runaspw, passwd_tries=2

Another interesting feature is to keep the DISPLAY variable set so that you can execute graphical tools:

CODE Keeping the DISPLAY variable alive
Defaults:john env_keep=DISPLAY

You can change dozens of default settings using the Defaults: directive. Fire up the sudoers manual page and search for Defaults.

If you however want to allow a user to run a certain set of commands without providing any password whatsoever, you need to start the commands with NOPASSWD:, like so:

CODE Allowing emerge to be ran as root without asking for a password
larry     localhost = NOPASSWD: /usr/bin/emerge

Bash completion

Users that want bash completion with sudo need to run this once.

user $sudo echo "complete -cf sudo" >> $HOME/.bashrc

Zshell completion

Users that want zsh completion for sudo can set the following in .zprofile and .zshrc respectively

FILE .zprofileAdding zshell completion
if [[ $EUID != 0 ]]; then
    typeset -xT SUDO_PATH sudo_path
    typeset -U sudo_path
    alias sudo="sudo env PATH=\"SUDO_PATH:$PATH\""
FILE .zshrcAdding zshell completion
zstyle ':completion:*:sudo:*' environ PATH="$SUDO_PATH:$PATH"

With the above change, all commands in the /sbin, /usr/sbin and /usr/local/sbin locations will be available to the shell for completion when the command is prefaced with 'sudo'.


Lister les privilèges

To inform yourself what your capabilities are, run sudo -l :

user $sudo -l
User larry may run the following commands on this host:
    (root)   /usr/libexec/xfsm-shutdown-helper
    (root)   /usr/bin/emerge
    (root)   /usr/bin/passwd [a-zA-Z0-9_-]*
    (root)   !/usr/bin/passwd root
    (apache) /usr/bin/pkill
    (apache) /bin/kill

Si des commandes se trouvent dans /etc/sudoers qui ne requièrent pas que vous saisissiez un mot de passe, il ne sera pas non plus nécessaire de saisir un mot de passe pour lister les entrées. Autrement, on pourrait vous demander votre mot de passe s'il n'est pas mémorisé.

Prolonger le temps de mémorisation du mot de passe

By default, if a user has entered their password to authenticate their self to sudo, it is remembered for 5 minutes. If the user wants to prolong this period, he can run sudo -v to reset the time stamp so that it will take another 5 minutes before sudo asks for the password again.

user $sudo -v

The inverse is to kill the time stamp using sudo -k.


  1. [1]Sudoers LDAP man Page