Sudo/fr

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 à connaitre 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 votre meilleure option. Avec sudo vous pouvez contrôler qui peut faire quoi. Ce guide est une petite introduction à ce merveilleux outil.

This article is meant as a quick introduction. The package is a lot more powerful than what is described here. It has special features for editing files as a different user (sudoedit), running from within a script (so it can background, read the password from standard in instead of the keyboard, ...), etc.

Please read the sudo and sudoers manual pages for more information.

Journalisation
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
The package allows the system administrator to grant permission to other users to execute one or more applications they would normally have no right to. Unlike using the  bit on these applications sudo gives a more fine-grained control on who can execute a certain command and when.

Avec sudo vous pouvez établir une liste claire de qui peut exécuter une application donnée. Si vous utilisiez le bit setuid, n'importe quel utilisateur ( ou n'importe quel utilisateur d'un groupe donné, selon l'autorisation accordée) serait capable d'exécuter cette application. Vous pouvez (et devriez probablement) demander à l'utilisateur de fournir un mot de passe lorsqu'il désire exécuter l'application concernée.

La configuration de sudo est gérée par le fichier. Ce fichier ne devrait jamais être édité via nano /etc/sudoers</tt> ou vim /etc/sudoers</tt> ou n'importe quel autre éditeur. Lorsque vous désirez changer ce fichier, vous devriez utiliser visudo</tt>.

Cet outil garantit que deux administrateurs ne sont pas en train d'éditer ce fichier au même moment, conserve les autorisations sur ce fichier et assure une vérification de la syntaxe pour être certain que vous n'avez pas laissé d'erreur fatale dedans.

Syntaxe de base
La partie la plus difficile de sudo</tt>, c'est la syntaxe du fichier. La syntaxe de base ressemble à ceci :

This syntax tells sudo</tt> that the user, identified by  and logged in on the system   can execute any of the commands listed in   as the root user. A more real-life example might make this more clear: allow the user larry to execute emerge</tt> if he is logged in on localhost:

The user name can also be substituted with a group name - in this case you should start the group name with a  sign. For instance, to allow any one in the wheel</tt> group to execute emerge</tt>:

You can extend the line to allow for several commands (instead of making a single entry for each command). For instance, to allow the same user to not only run emerge</tt> but also ebuild</tt> and emerge-webrsync</tt> as root:

You can also specify a precise command and not only the tool itself. This is useful to restrict the use of a certain tool to a specified set of command options. The sudo</tt> 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.

Testons cela :

The password that sudo</tt> 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.

You should know that sudo</tt> does not alter the  variable: any command you place after sudo</tt> is treated from your environment. If you want the user to run a tool in for instance he should provide the full path to sudo</tt>, like so:

Syntaxe de base avec LDAP
Les options suivantes de la variable USE sont nécessaire pour la prise en charge de LDAP.

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

{{FileBox|filename=/etc/ldap.conf.sudo|title=Please chmod 400 when done|1= host ldap.example.com port 389 base dc=example,dc=com uri ldap://ldap.example.com/ ldap_version 3 sudoers_base ou=SUDOers,dc=example,dc=com bind_policy soft }}
 * 1) See ldap.conf(5) and README.LDAP for details
 * 2) This file should only be readable by root
 * 1) supported directives: host, port, ssl, ldap_version
 * 2) uri, binddn, bindpw, sudoers_base, sudoers_debug
 * 3) tls_{checkpeer,cacertfile,cacertdir,randfile,ciphers,cert,key
 * 1) uri ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock
 * 1) ssl start_tls
 * 1) sudoers_debug 2

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

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.

(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  est un alias représentant tout ce qui est possible en matière de réglage.

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

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

More interesting is to define a set of users who can run software administrative applications (such as <tt>emerge</tt> and <tt>ebuild</tt>) on the system and a group of administrators who can change the password of any user, except 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 <tt>apache</tt> for the web server) and want to allow certain users to perform administrative steps as that user (like killing zombie processes).

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

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

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

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

Passwords and default settings
By default, <tt>sudo</tt> asks the user to identify himself using his own password. Once a password is entered, <tt>sudo</tt> 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  directive in  to change the default behavior for a user.

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

A setting of  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. In the following example we also set the number of retries (how many times the user can re-enter a password before <tt>sudo</tt> fails) to  instead of the default 3:

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

You can change dozens of default settings using the  directive. Fire up the <tt>sudoers</tt> manual page and search for.

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, like so:

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

Zshell completion
Users that want zsh completion for sudo can set the following in and  respectively

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

Lister les privilèges
Pour connaître vos propres autorisations, exécutez la commande <tt>sudo -l</tt> :

Si des commandes se trouvent dans 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 <tt>sudo</tt>, it is remembered for 5 minutes. If the user wants to prolong this period, he can run <tt>sudo -v</tt> to reset the time stamp so that it will take another 5 minutes before <tt>sudo</tt> asks for the password again.

The inverse is to kill the time stamp using <tt>sudo -k</tt>.