infra / linux-bash
Utilisateurs et groupes
Explication
Sur un serveur partagé par plusieurs personnes ou plusieurs applications, il faut pouvoir dire précisément qui a le droit de faire quoi. Un utilisateur représente une identité, une personne ou un service, tandis qu'un groupe représente un ensemble d'utilisateurs partageant les mêmes droits — un système à deux niveaux qui évite de configurer les permissions individuellement pour chaque personne.
Ce que vous allez apprendre
- Comprendre le rôle des trois fichiers
/etc/passwd,/etc/groupet/etc/shadow - Créer un utilisateur applicatif avec
useradd -m -s /bin/bashet lui donner un mot de passe - Ajouter un utilisateur à un groupe sans écraser ses groupes existants (
usermod -aG) - Comprendre pourquoi
sudoersdoit toujours être édité avecvisudoet jamais un autre éditeur - Changer d'identité temporairement avec
su -etsudo -uselon le besoin
Dans quel contexte ?
Un nouveau développeur rejoint l'équipe et a besoin d'un accès au serveur de staging pour déboguer un conteneur Docker. L'administrateur système doit créer son compte, l'ajouter au groupe docker pour qu'il puisse lancer des conteneurs sans sudo à chaque fois, mais sans lui retirer accidentellement son accès au groupe devs dont il a aussi besoin. C'est exactement là que le piège usermod -G sans -a peut faire des dégâts silencieux.
Une fois ça posé, où ces informations sont-elles stockées ?
Trois fichiers font tout le travail.
| Fichier | Contenu | Qui peut le lire |
|---|---|---|
/etc/passwd | Liste des utilisateurs (login, UID, home, shell) | Tout le monde |
/etc/group | Liste des groupes et de leurs membres | Tout le monde |
/etc/shadow | Mots de passe hachés (jamais en clair) | Root uniquement |
Comprendre que ce sont de simples fichiers texte démystifie beaucoup la gestion des comptes. Il n'y a pas de base de données mystérieuse derrière : juste des fichiers structurés que des commandes comme useradd modifient pour toi.
Piège dangereux
sudo usermod -G docker ned (sans -a) remplace TOUS les groupes secondaires de ned par uniquement docker — il perd d'un coup son accès à devs, www-data ou tout autre groupe dont il dépendait, souvent sans message d'erreur visible. Le réflexe à retenir : toujours -aG ensemble (usermod -aG docker ned), jamais -G seul.
Pour aller plus loin : pourquoi visudo et jamais un éditeur classique
Le fichier sudoers contrôle qui peut devenir root sur la machine. Une simple erreur de syntaxe dedans peut rendre sudo totalement inutilisable pour tout le monde, y compris pour toi.
Bonne pratique
visudo valide la syntaxe du fichier avant de l'enregistrer réellement, ce qui empêche de se retrouver enfermé dehors avec un sudoers cassé. N'édite jamais /etc/sudoers avec nano ou vim directement : passe systématiquement par sudo visudo.
Maintenant que tu sais gérer qui a accès à quoi, la prochaine leçon s'intéresse à un autre mécanisme central : comment bash retrouve tes commandes grâce aux variables d'environnement.
Commandes & code
Utilisateurs et groupes
# Fichiers clés
# /etc/passwd -> liste des utilisateurs (login:x:UID:GID:commentaire:home:shell)
# /etc/shadow -> mots de passe hashés, lisible uniquement par root
# /etc/group -> liste des groupes
whoami # utilisateur courant
id # UID, GID, et tous les groupes de l'utilisateur courant
id ned # infos sur un utilisateur précis
# Création / gestion d'utilisateurs
sudo useradd -m -s /bin/bash ned # -m crée le home, -s fixe le shell
sudo useradd -m -G devs,docker ned # ajoute directement à des groupes secondaires
sudo passwd ned # définit/change le mot de passe
sudo usermod -aG docker ned # ajoute ned au groupe docker (-a = append, indispensable)
sudo usermod -s /bin/zsh ned # change le shell par défaut
sudo usermod -L ned # verrouille le compte (empêche la connexion)
sudo usermod -U ned # déverrouille le compte
sudo userdel ned # supprime l'utilisateur (garde le home)
sudo userdel -r ned # supprime l'utilisateur ET son home
# Groupes
sudo groupadd devs # crée un groupe
sudo groupmod -n developpeurs devs # renomme un groupe
sudo gpasswd -d ned devs # retire ned du groupe devs
sudo groupdel devs # supprime un groupe
groups ned # liste les groupes de ned
cat /etc/group | grep docker # qui appartient au groupe docker
# Changer d'identité
su - ned # ouvre un shell en tant que ned (avec son environnement)
sudo -u ned whoami # exécute une seule commande en tant que ned
sudo -i # shell root complet (équivalent su - root)
sudo -l # liste ce que l'utilisateur courant peut faire avec sudo
# sudoers : /etc/sudoers (à éditer UNIQUEMENT avec visudo, jamais un éditeur classique)
sudo visudo
# Exemple de ligne : autoriser ned à redémarrer nginx sans mot de passe
# ned ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx
# Expiration de compte
sudo chage -l ned # affiche la politique d'expiration du mot de passe
sudo chage -M 90 ned # force un changement de mot de passe tous les 90 joursRésumé
/etc/passwd,/etc/shadow,/etc/groupsont les trois fichiers source de vérité.usermod -aG(avec le-a!) pour ajouter un utilisateur à un groupe sans le retirer des autres.visudovalide la syntaxe avant sauvegarde : unsudoerscassé peut bloquer tout accès root.
Exercices pratiques
Mission : intégrer un développeur sans casser ses accès existants
Objectif : Ajouter un utilisateur à un groupe applicatif sans lui retirer ses accès existants, et sécuriser l'édition de sudoers.
Contexte
Un nouveau développeur, ned, a besoin d'un accès au serveur de staging pour déboguer un conteneur Docker. Il possède déjà un compte, membre du groupe devs. Un collègue pressé propose une commande rapide pour lui donner accès à Docker — et c'est exactement le genre de raccourci qui peut faire des dégâts silencieux.