sudo/fr

From Gentoo Wiki
Revision as of 18:25, 19 September 2013 by Jaaf (Talk | contribs)

Jump to: navigation, search
Other languages:English 100% • ‎español 100% • ‎français 100% • ‎日本語 21% • ‎한국어 4% • ‎русский 100%

External resources

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.

À propos de Sudo

Accorder des autorisations

Le paquet app-admin/sudo permet à l'administrateur du système d'accorder des autorisations à d'autres utilisateurs pour exécuter une ou plusieurs applications qu'ils n'auraient normalement pas le droit d'exécuter. À la différence de l'utilisation du bit setuid sur ces applications, sudo permet un contrôle plus fin sur qui peut exécuter une certaine commande et sur quand il peut le faire.

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.

Journalisation

Un avantage supplémentaire de sudo, c'est qu'elle peut tenir un journal de toutes les tentatives (réussies ou pas) d'exécution d'une application. Ceci est très utile si vous voulez garder la trace de qui a commis l'erreur fatale qui vous a demandé 10 heures à réparer.

Configurer sudo

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

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.

À propos de ce guide

Ce guide ne prétend être qu'une introduction rapide. Le paquet sudo est beaucoup plus puissant que ce que nous décrivons ici. Il possède des fonctionnalités spéciales pour éditer des fichiers en tant qu'un autre utilisateur (sudoedit ), depuis un script (de telle manière qu'il puisse fonctionner en arrière-plan, lire le mot de passe depuis l'entrée standard plutôt que du clavier,...), etc.

Reportez-vous aux pages de manuel de sudo et de sudoers pour une information plus complète.

Syntaxe de sudoers

Syntaxe de base

La partie la plus difficile de sudo, c'est la syntaxe du fichier /etc/sudoers. La syntaxe de base ressemble à ceci :

CodeSyntaxe de base de /etc/sudoers

user  host = commands

Cette syntaxe indique à sudo que l'utilisateur, identifié par user et connecté au système host peut exécuter n'importe quelle commande listée dans commands en tant qu'utilisateur root. Un exemple plus réel pourrait rendre cela plus clair : autoriser l'utilisateur swift à exécuter emerge s'il est connecté à l'hôte local :

CodeExemple réaliste de /etc/sudoers

swift  localhost = /usr/bin/emerge
Note
Le nom d'hôte doit corresponde à ce que retourne la commande hostname.

Un gros avertissement est cependant de mise : n'autorisez pas un utilisateur à exécuter une application qui lui permette d'élever ses autorisations. Par exemple, autoriser des utilisateurs à exécuter emerge en tant que root peut en effet leur donner un accès complet au système en tant que root parce qu'emerge peut être manipulé pour changer le système de fichier actif à l'avantage de l'utilisateur. Si vous ne faites pas confiance à vos utilisateurs de sudo, ne leur donnez aucune autorisation.

Le nom d'utilisateur peut aussi être remplacé par un nom de groupe. Dans ce cas, vous devriez commencer le nom du groupe avec un signe %. Par exemple, pour autoriser n'importe quel utilisateur du groupe wheel à exécuter emerge :

CodeAutoriser les membres du groupe wheel à éxecuter emerge

%wheel  localhost = /usr/bin/emerge

Vous pouvez étendre la ligne pour autoriser plusieurs commandes (au lieu de faire une entrée simple pour chacune des commandes). Par exemple, pour autoriser le même utilisateur à exécuter, pas seulement emerge ,mais aussi ebuild et emerge-webrsync en tant que root :

CodeCommandes multiples

swift  localhost = /usr/bin/emerge, /usr/bin/ebuild, /usr/sbin/emerge-webrsync

Vous pouvez aussi spécifier une commande précise et pas seulement un outil. Ceci est utile pour restreindre l'utilisation d'un outil donné à un certain jeu d'options de commande. L'outil sudo autorise les passe-partout du style shell (aussi connu sous le nom de meta caractères ou de caractères glob) à être utilisés dans les noms de fichiers ou dans les arguments de la ligne de commande dans le fichier sudoers. Notez qu'il ne s'agit pas d'expressions régulières.

Testons cela :

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

Le mot de passe requis par sudo est le propre mot de passe de l'utilisateur, pas celui de root. Ceci garantit qu'aucun terminal que vous avez laissé accidentellement ouvert aux autres ne pourra être utilisé par des gens mal intentionnés.

Vous devriez savoir que sudo ne modifie pas la variable ${PATH} : toute commande placée après sudo est traitée dans votre environnement. Si vous voulez que l'utilisateur exécute un outil dans /sbin par exemple, il devrait fournir le chemin complet à sudo de cette manière :

user $ sudo /usr/sbin/emerge-webrsync

Utiliser des alias

Dans des environnements plus étendus, avoir à entrer tous les utilisateurs encore et encore (ou des hôtes, ou des commandes) peut sembler très rébarbatif. Pour faciliter l'administration de /etc/sudoers, vous pouvez définir des alias. Le format pour déclarer un alias est très simple :

CodeDéclarer des alias dans /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.

Un exemple d'utilisation de l'alias ALL pour autoriser n'importe quel utilisateur à exécuter la commande shutdown lorsqu'il est connecté localement est :

CodeAutoriser n'importe quel utilisateur à éxecuter shutdown

ALL  localhost = /sbin/shutdown

Un autre exemple consiste à autoriser l'utilisateur swift à exécuter la commande emerge en tant que root sans tenir compte de l'hôte auquel il est connecté :

CodeAutoriser un utilisateur à exécuter une application sans tenir compte de l'hôte auquel il est connecté

swift   ALL = /usr/bin/emerge

Plus intéressant encore, consiste à définir un jeu d'utilisateurs qui peuvent exécuter des programmes d'administration (tels que emerge et ebuild ) sur le système et un groupe d'administrateurs qui peuvent changer le mot de passe de n'importe quel utilisateur, exception faite de root !

CodeUtiliser des alias pour des utilisateurs et des commandes

User_Alias  SOFTWAREMAINTAINERS = swift, john, danny
User_Alias  PASSWORDMAINTAINERS = swift, sysop
Cmnd_Alias  SOFTWARECOMMANDS    = /usr/bin/emerge, /usr/bin/ebuild
Cmnd_Alias  PASSWORDCOMMANDS    = /usr/bin/passwd [a-zA-Z0-9_-]*, !/usr/bin/passwd root
  
SOFTWAREMAINTAINERS  localhost = SOFTWARECOMMANDS
PASSWORDMAINTAINERS  localhost = PASSWORDCOMMANDS

Exécution non root

Il est aussi possible d'autoriser un utilisateur à exécuter une application au nom d'un autre utilisateur autre que root. Ceci peut être très intéressant si vous exécutez des applications au nom d'un autre utilisateur (par exemple apache pour le serveur web ) et voulez autoriser certains utilisateurs à accomplir des tâches d'administration au nom de l'utilisateur ( comme tuer des processus zombie).

Dans le fichier /etc/sudoers vous listez les utilisateur entre ( et ) avant la liste des commandes :

CodeSyntaxe pour une exécution non-root

users  hosts = (run-as) commands

Par exemple, pour autoriser swift à exécute l'outil kill au nom de l'utilisateur apache ou gorg :

CodeExemple d'exécution non root

Cmnd_Alias KILL = /bin/kill, /usr/bin/pkill
  
swift   ALL = (apache, gorg) KILL

Avec ceci de défini, l'utilisateur peut exécuter sudo -u pour choisir le nom de l'utilisateur au nom de qui il veut exécuter l'application :

user $ sudo -u apache pkill apache

Vous pouvez définir un alias pour que l'utilisateur puisse exécuter une application comme utilisant la directive Runas_Alias. Son utilisation est identique à celle des autres directives _Alias que nous avons vues précédemment.

Mots de passe et réglages par défaut

Par défaut, sudo demande à l'utilisateur de s'identifier en utilisant son propre mot de passe. Une fois de mot de passe saisi, sudo s'en souvient pendant cinq minutes, permettant à l'utilisateur de se focaliser sur ce qu'il veut faire et de ne pas avoir à rentrer son mot de passe à tout bout de champ.

Bien-entendu, ce comportement peut être modifié : vous pouvez définir la directive Default: dans /etc/sudoers pour changer le comportement par défaut pour un utilisateur.

Par exemple, pour changer le temps de mémorisation de 5 minutes à 0 (pas de mémorisation du mot de passe) :

CodeChanger la valeur de temps de mémorisation

Defaults:swift  timestamp_timeout=0

Une valeur fixée à -1 étendrait ce temps à l'infini (jusqu'au redémarrage du système).

Un réglage différent, pourrait être de requérir le mot de passe de l'utilisateur au nom duquel la commande devrait être exécutée et pas celui de l'utilisateur. Ceci est possible en utilisant runaspw. Dans l'exemple suivant, nous définissons aussi le nombre de tentatives de saisie du mot de passe autorisé avant que la commande sudo n'échoue à 2 au lieu de 3 par défaut :

CodeRequérant le mot de passe de root plutôt que celui de l'utilisateur

Defaults:john   runaspw, passwd_tries=2

Une autre fonctionnalité intéressante est de conserver la variable DISPLAY définie de manière à permettre l'utilisation d'outils graphiques :

CodeLaisser la variable DISPLAY active

Defaults:john env_keep=DISPLAY

Vous pouvez changer des douzaines de réglages par défaut en utilisant la directive Defaults:. Ouvrez la page de manuel de sudo et cherchez Defaults:.

Si, cependant, vous voulez autoriser un utilisateur à exécuter un certain jeu de commandes sans entrer un quelconque mot de passe, vous devez démarrer les commandes par NOPASSWD:, comme ceci :

CodeAutoriser emerge à être exécutée par un utilisateur donné en tant que root sans demander de mot de passe

swift     localhost = NOPASSWD: /usr/bin/emerge

Utiliser sudo

Lister les privilèges

Pour connaître vos propres autorisations, exécutez la commande sudo -l :

user $ sudo -l
User swift 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

Par défaut, si un utilisateur a saisi son mot de passe pour s'identifier auprès de sudo, ce mot de passe est mémorisé 5 minutes. Si l'utilisateurs désire prolonger ce bail, il peut exécuter sudo -v pour remettre à zéro le compteur de temps de manière telle qu'il dispose d'encore 5 minutes avant que sudo ne lui réclame à nouveau son mot de passe

user $ sudo -v

L'inverse consiste à tuer le compteur avec sudo -k.

Améliorations de sudo

Auto-complétion dans Bash

Les utilisateurs qui désirent une auto-complétion dans bash doivent exécuter ceci une fois.

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

Complétion Zshell

Les utilisateurs qui désirent une complétion zsh pour sudo can peuvent définir ce qui suit dans .zprofile et .zshrc respectivement.

File.zprofileAdding zshell completion

if [[ $EUID != 0 ]]; then
    typeset -xT SUDO_PATH sudo_path
    typeset -U sudo_path 
    sudo_path=({,/usr/local,/usr}/sbin(N-/))
    alias sudo="sudo env PATH=\"SUDO_PATH:$PATH\""
fi
File.zshrcAdding zshell completion

zstyle ':completion:*:sudo:*' environ PATH="$SUDO_PATH:$PATH"

Avec les changements ci-dessus, toutes les commandes dans les emplacements /sbin, /usr/sbin et /usr/local/sbin seront disponibles au shell pour complétion lorsque la commande sera introduite par 'sudo'.