Utilisateurs, groupes et sudo sous Linux

Un compte utilisateur Linux est une identité, repérée par un numéro (UID), qui possède des fichiers et lance des processus ; un groupe (GID) réunit des comptes pour leur donner les mêmes droits ; sudo permet à un compte autorisé d'exécuter une commande en administrateur. Ce chapitre décrit les fichiers qui stockent les comptes, les commandes pour les créer, les modifier et les supprimer, et la façon de configurer sudo pour que chacun n'ait que les privilèges dont il a besoin.

Les trois sortes de comptes

Un service qui tourne sous son propre compte système (nginx sous www-data) ne peut toucher que les fichiers de ce compte : si une faille permet de le détourner, l'attaquant n'obtient pas les droits de root. C'est le moindre privilège appliqué aux programmes.

Les fichiers des comptes

/etc/passwd, lisible par tous, décrit chaque compte sur une ligne de sept champs séparés par : :

clambert:x:1000:1000:Chloé Lambert,,,:/home/clambert:/bin/bash
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

/etc/shadow, lisible seulement par root et le groupe shadow, contient les mots de passe hachés et leurs règles de validité :

clambert:$y$j9T$Qm1...$Lk8...:20741:0:99999:7:::

Le deuxième champ commence par $y$ : l'algorithme est yescrypt, celui de Debian depuis la version 11, conçu pour rendre les essais massifs coûteux. Un ! ou un * à cet endroit signifie qu'aucun mot de passe ne permet de se connecter (compte verrouillé, ou compte système). Les champs suivants sont la date du dernier changement (en jours depuis le 1er janvier 1970 : 20741 = 15 octobre 2026), l'âge minimal et maximal du mot de passe, le délai d'avertissement, puis la date d'expiration du compte.

/etc/group liste les groupes et leurs membres secondaires :

sudo:x:27:clambert,mdiallo,amercier
adm:x:4:clambert,mdiallo
web-dev:x:1004:dev-igarnier,dev-hpetit

Chaque compte a un groupe principal (le 4e champ de /etc/passwd, en général un groupe du même nom créé avec lui) et autant de groupes secondaires qu'il faut. Les groupes qui comptent sur Debian : sudo (droit d'utiliser sudo), adm (lecture des journaux de /var/log), systemd-journal (lecture de tout le journal).

Créer, modifier et supprimer des comptes

Debian fournit deux jeux de commandes. adduser, propre à Debian et Ubuntu, pose les questions et applique les bons réglages (dossier personnel, groupe du même nom, copie de /etc/skel). useradd, commune à toutes les distributions, ne fait que ce que ses options demandent : c'est elle qu'on trouve dans les scripts et sur RHEL.

# Créer le groupe des développeurs du prestataire, puis leurs comptes
sudo addgroup web-dev
sudo adduser --comment "Inès Garnier (prestataire)" dev-igarnier
sudo adduser --comment "Hugo Petit (prestataire)" dev-hpetit

# Les ajouter au groupe (deux formes équivalentes)
sudo adduser dev-igarnier web-dev
sudo usermod -aG web-dev dev-hpetit

# L'équivalent avec useradd, sans question
sudo useradd -m -s /bin/bash -c "Hugo Petit (prestataire)" -G web-dev dev-hpetit
sudo passwd dev-hpetit

Dans usermod -aG, le -a (append) est essentiel : sans lui, -G remplace la liste des groupes secondaires, et le compte perd tous les autres.

Les comptes des prestataires sont des comptes temporaires : leur fin de mission est connue. chage -E les fait expirer tout seuls à la date prévue, même si personne ne pense à les supprimer.

Les comptes Linux et l'annuaire

Dans une entreprise équipée d'Active Directory, créer les comptes à la main sur chaque serveur Linux ne tient pas longtemps. On peut joindre un serveur Debian au domaine avec realmd et sssd : les comptes et les groupes du domaine (ad.sorbier.example) se connectent alors avec leur mot de passe habituel. Chez Sorbier, les deux serveurs Debian n'ont que quatre ou cinq comptes d'administration et srv-web est en DMZ, où l'on évite de dépendre de l'annuaire : les comptes restent locaux. L'annuaire lui-même est traité dans le cours Windows Server.

su et sudo

su (substitute user) ouvre un shell sous un autre compte, en demandant le mot de passe de ce compte : su - ouvre une session root complète si root a un mot de passe. sudo exécute une commande en administrateur en demandant ton propre mot de passe, à condition que la configuration t'y autorise.

C'est pourquoi on administre avec sudo et des comptes nominatifs : quand un fichier de configuration a été modifié, le journal dit qui l'a fait. Après une première saisie, sudo garde ton mot de passe en mémoire 15 minutes dans ce terminal.

clambert@srv-web:~$ sudo systemctl reload nginx
[sudo] Mot de passe de clambert :
clambert@srv-web:~$ sudo journalctl _COMM=sudo --since today | tail -n 2
nov. 04 09:52:10 srv-web sudo[2741]: clambert : TTY=pts/0 ; PWD=/home/clambert ; USER=root ; COMMAND=/usr/bin/systemctl reload nginx
nov. 04 09:52:10 srv-web sudo[2741]: pam_unix(sudo:session): session opened for user root(uid=0) by clambert(uid=1000)

Configurer sudo : le fichier sudoers

Les règles de sudo sont dans /etc/sudoers et dans les fichiers de /etc/sudoers.d/. Sur Debian, la ligne qui donne tous les droits au groupe sudo est déjà là :

%sudo   ALL=(ALL:ALL) ALL

Elle se lit : les membres du groupe (%) sudo, depuis n'importe quelle machine (ALL), peuvent exécuter en tant que n'importe quel utilisateur et groupe ((ALL:ALL)) n'importe quelle commande (ALL).

On ne modifie pas /etc/sudoers lui-même : on ajoute un fichier dans /etc/sudoers.d/, toujours avec visudo, qui vérifie la syntaxe avant d'enregistrer. Une erreur de syntaxe dans un fichier sudoers désactive sudo pour tout le monde, et sans mot de passe root, il ne reste plus que le mode de secours pour réparer.

Les développeurs du prestataire doivent pouvoir recharger nginx après une modification du site, et rien d'autre :

sudo visudo -f /etc/sudoers.d/web-dev

# Développeurs du prestataire : tester et recharger nginx, rien d'autre
%web-dev ALL=(root) /usr/sbin/nginx -t, /usr/bin/systemctl reload nginx

Les chemins sont complets, les arguments exacts : dev-igarnier pourra taper sudo systemctl reload nginx, mais sudo systemctl stop nginx sera refusé. sudo -l affiche ce qu'un compte a le droit de faire.

dev-igarnier@srv-web:~$ sudo -l
...
L'utilisateur dev-igarnier peut utiliser les commandes suivantes sur srv-web :
    (root) /usr/sbin/nginx -t, /usr/bin/systemctl reload nginx
dev-igarnier@srv-web:~$ sudo systemctl restart ssh
Désolé, l'utilisateur dev-igarnier n'est pas autorisé à exécuter '/usr/bin/systemctl restart ssh' en tant que root sur srv-web.

Deux règles de nommage : un fichier de /etc/sudoers.d/ dont le nom contient un point ou finit par ~ est ignoré (web-dev.conf ne serait jamais lu), et ses droits doivent être 0440 (visudo s'en charge). sudo visudo -c vérifie tous les fichiers d'un coup.

Exercices

root:x:0:0:root:/root:/bin/bash
mdiallo:x:1001:1001:Moussa Diallo,,,:/home/mdiallo:/bin/bash
_chrony:x:996:996:Chrony daemon,,,:/var/lib/chrony:/usr/sbin/nologin

sudo adduser --comment "Yanis Roux (prestataire)" dev-yroux
sudo usermod -aG web-dev dev-yroux
sudo chage -E 2027-04-01 dev-yroux
id dev-yroux
sudo chage -l dev-yroux

%support ALL=(ALL) NOPASSWD: /usr/bin/vim, /usr/bin/systemctl *

%support ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/journalctl -u nginx