Chapitre 3.1 — Utilisateurs & groupes

⏱️ TL;DR — Linux est un système multi-utilisateurs : plusieurs comptes se partagent la machine, chacun avec son identité, ses fichiers et ses droits. Tout en haut, root (identifiant uid 0) est tout-puissant : il n’a aucune limite, donc aucune erreur ne lui est pardonnée. En dessous, des utilisateurs humains (toi, tes collègues) et des utilisateurs système dédiés à des services (comme www-data pour le serveur web) qui ne servent jamais à se connecter. Les comptes vivent dans /etc/passwd, les groupes dans /etc/group, les mots de passe (chiffrés) dans /etc/shadow — trois fichiers qu’on lit pour comprendre, mais qu’on ne modifie jamais à la main. On les manipule avec des commandes sûres : id, adduser, usermod, passwd, su.

🎯 Objectifs

• Comprendre pourquoi Linux est multi-utilisateurs et ce que ça implique sur un serveur.
• Distinguer root, utilisateurs humains et utilisateurs système.
• Savoir qui tu es et à quels groupes tu appartiens (id, whoami, groups).
• Créer, modifier et supprimer un utilisateur, et l’ajouter à un groupe.
• Comprendre la notion de propriété (owner:group) et pourquoi chaque service a son utilisateur.

Une machine, plusieurs identités

Sur ton portable, tu ne penses jamais « en tant que qui » tu agis : il n’y a que toi. Sur un serveur, cette question est centrale. Linux attribue à chaque compte un identifiant numérique, l’UID (User ID), et à chaque groupe un GID (Group ID). Le noyau ne raisonne qu’en numéros ; les noms (deploy, www-data) sont là pour nous, les humains.

Chaque utilisateur possède :

• un nom de connexion (deploy) et un UID ;
• un groupe principal (souvent un groupe à son nom) et éventuellement des groupes secondaires ;
• un répertoire personnel (le home, ex. /home/deploy) où il range ses fichiers ;
• un shell de connexion (souvent /bin/bash), le programme lancé quand il ouvre une session.

Tout ça, tu le vois d’un coup d’œil avec id :

id
# uid=1000(deploy) gid=1000(deploy) groups=1000(deploy),27(sudo)
# -> je suis "deploy" (UID 1000), mon groupe principal est "deploy",
#    et j'appartiens aussi au groupe "sudo" (le droit d'administrer)

🐚 Au terminal — Trois commandes pour savoir où tu en es à tout moment :

whoami        # affiche juste mon nom d'utilisateur courant
id            # UID, GID et tous mes groupes
groups        # la liste de mes groupes, en clair
who           # qui d'autre est connecté à la machine, sur quel terminal

root : le compte tout-puissant

root est le compte administrateur de Linux, celui dont l’UID vaut 0. C’est une règle en dur dans le noyau : UID 0 = aucune restriction. root peut lire, écrire et supprimer n’importe quel fichier, tuer n’importe quel processus, reconfigurer le réseau, formater le disque. Il n’y a pas de garde-fou : une commande destructrice tapée en root s’exécute sans broncher.

Cette puissance est nécessaire (installer des paquets, éditer /etc, gérer les services), mais elle est dangereuse au quotidien : une faute de frappe, un script douteux, une commande copiée-collée sans comprendre, et tu casses le système ou tu ouvres une faille. D’où le principe qui structure tout le chapitre suivant : on ne travaille pas en root. On crée un utilisateur normal et on lui donne le droit de monter en root ponctuellement avec sudo (Chapitre 3.2).

⚠️ Piège — Tout faire en root « parce que c’est plus simple ». Ça marche… jusqu’au jour où un rm -rf mal ciblé efface le mauvais dossier, ou qu’un process compromis hérite des pleins pouvoirs. Sur un VPS neuf, beaucoup de fournisseurs te donnent root par défaut : ta première tâche est d’en sortir (créer un user, lui donner sudo, se reconnecter avec lui).

Humains vs système : deux familles d’utilisateurs

Tous les comptes ne sont pas des personnes. Linux distingue deux familles :

• Les utilisateurs humains : toi, tes collègues. UID typiquement ≥ 1000, un vrai home dans /home/, un shell interactif, un mot de passe pour se connecter.
• Les utilisateurs système : des comptes dédiés à des services, créés par les logiciels à l’installation. UID bas (souvent < 1000). Ils n’ont pas vocation à se connecter : pas de mot de passe utilisable, souvent un shell « désactivé » (/usr/sbin/nologin). Exemples : www-data (le serveur web Nginx/Apache), postgres (la base de données), redis, sshd.

Pourquoi cette séparation ? Pour le cloisonnement. Si Nginx tourne sous l’utilisateur www-data (aux droits très limités) plutôt qu’en root, alors une faille dans Nginx ne donne à l’attaquant que les maigres droits de www-data, pas les clés du royaume. C’est le moindre privilège appliqué aux services : chaque programme tourne avec le strict minimum de droits nécessaires.

🔒 Sécurité — Un service ne doit jamais tourner en root s’il peut l’éviter. Le compte système dédié (www-data, postgres, ou ton propre deploy pour ton app) est une barrière de confinement : il limite les dégâts si le service est compromis. On y revient concrètement avec systemd et sa directive User= (Chapitre 3.5).

Où vivent les comptes : passwd, group, shadow

Trois fichiers texte dans /etc décrivent tous les comptes de la machine. On les lit pour comprendre ; on ne les édite pas à la main (les commandes dédiées le font proprement et sans risque de corruption).

/etc/passwd — la liste des utilisateurs. Une ligne par compte, sept champs séparés par : (malgré son nom, il ne contient plus les mots de passe) :

deploy:x:1000:1000:Deploy User:/home/deploy:/bin/bash
# nom : x : UID : GID : commentaire : home : shell
# le "x" renvoie vers /etc/shadow pour le mot de passe

/etc/group — la liste des groupes et de leurs membres :

sudo:x:27:deploy,alice
# nom du groupe : x : GID : membres secondaires

/etc/shadow — les mots de passe chiffrés (hashés) et leur politique d’expiration. Ce fichier est lisible par root uniquement : c’est ce qui protège les empreintes de mots de passe. On n’y touche jamais directement.

⚠️ Piège — Ouvrir /etc/passwd ou /etc/shadow dans un éditeur et corriger « à la main ». Une virgule ou un : de travers peut verrouiller tout le monde dehors, y compris root. Utilise toujours les commandes (adduser, usermod, passwd) : elles valident la syntaxe et posent les bons verrous. Pour éditer les comptes en sécurité, l’outil dédié est vipw (et vigr pour les groupes), qui verrouille le fichier pendant l’édition.

Créer, modifier, supprimer un utilisateur

Sur Debian/Ubuntu, deux niveaux d’outils coexistent :

• adduser / deluser : scripts conviviaux (interactifs), qui créent le home, demandent le mot de passe, posent des valeurs par défaut sensées. À privilégier au quotidien.
• useradd / userdel / usermod : commandes bas niveau (POSIX), plus verbeuses, présentes partout, idéales dans les scripts.

# Créer un utilisateur humain "deploy" (interactif : mot de passe, infos)
sudo adduser deploy
# -> crée /home/deploy, un groupe "deploy", copie les fichiers de /etc/skel
 
# Créer le même en bas niveau (non interactif, pour un script)
sudo useradd -m -s /bin/bash deploy   # -m crée le home, -s fixe le shell
sudo passwd deploy                     # définir/changer son mot de passe

Ajouter un utilisateur à un groupe est l’opération la plus fréquente (donner l’accès sudo, l’accès à un dossier partagé, au groupe docker…). La formule à retenir par cœur :

sudo usermod -aG sudo deploy
# -a = append (AJOUTE au lieu de remplacer), -G = groupes secondaires
# ici : ajoute "deploy" au groupe "sudo"

⚠️ Piège — Oublier le -a dans usermod -aG. usermod -G sudo deploy (sans -a) remplace tous les groupes secondaires de deploy par le seul sudo — tu peux ainsi le retirer sans le vouloir de docker, www-data, etc. La règle : pour ajouter un groupe, c’est toujours -aG, jamais -G seul.

💡 Réflexe — Après avoir ajouté quelqu’un à un groupe, l’appartenance n’est prise en compte qu’à la prochaine session. L’utilisateur doit se déconnecter puis reconnecter (ou ouvrir un nouveau shell de login) pour que son nouveau groupe soit actif. Un groups juste après l’ajout, dans la même session, ne montrera pas encore le changement — c’est normal, pas un bug.

Autres gestes courants :

passwd                 # changer MON propre mot de passe
sudo passwd deploy     # (en admin) changer celui de "deploy"
su - deploy            # devenir "deploy" (le tiret recharge son environnement : home, PATH)
exit                   # revenir à mon compte précédent
sudo deluser deploy              # supprimer l'utilisateur (garde son home par défaut)
sudo deluser --remove-home deploy   # le supprimer AVEC son répertoire personnel

📚 La doc — Chaque commande a sa page man faisant autorité : man adduser, man useradd, man usermod, man passwd. Les options exactes varient d’une distribution à l’autre : en cas de doute, le man de ta machine est la seule vérité.

Home, propriété et cloisonnement

Chaque utilisateur a son répertoire personnel (le home), typiquement /home/deploy, où il stocke ses fichiers, sa config (~/.bashrc), ses clés SSH (~/.ssh). root, lui, a un home à part : /root.

Surtout, tout fichier appartient à un utilisateur ET à un groupe — sa propriété (owner:group). C’est le fondement des permissions (Chapitre 3.3) : les droits d’un fichier s’appliquent différemment à son propriétaire, à son groupe, et aux autres. On lit cette propriété avec ls -l :

ls -l /var/www/formacampus
# drwxr-xr-x 4 deploy www-data 4096 ... .
#              ^^^^^^ ^^^^^^^^
#              owner  group
# -> ce dossier appartient à l'utilisateur "deploy" et au groupe "www-data"

C’est un montage classique en prod : les fichiers appartiennent à deploy (qui déploie et écrit) mais au groupe www-data (que le serveur web peut lire). Chacun a juste ce qu’il lui faut.

🧭 Sur FormaCampus — Sur son VPS neuf, l’équipe reçoit un accès root du fournisseur. Geste numéro un : adduser deploy, puis usermod -aG sudo deploy pour lui donner les droits d’admin à la demande. C’est ce compte deploy — jamais root — qui servira tout au long du cours : se connecter en SSH, déployer le front Next.js et l’API Symfony, gérer les services. Postgres, lui, tournera sous son propre utilisateur système postgres, et Nginx sous www-data. Trois identités, trois périmètres de droits : si l’une est compromise, les deux autres tiennent.

✏️ Exercices

Exercice 1 — Lis une ligne de passwd. On te donne cette ligne de /etc/passwd : www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin. Est-ce un utilisateur humain ou système ? Comment le sais-tu, et à quoi sert le champ /usr/sbin/nologin ?

Exercice 2 — Crée l’utilisateur de déploiement. Écris les commandes pour créer un utilisateur deploy, lui donner un mot de passe, et l’ajouter au groupe sudo — sans écraser ses autres groupes.

sudo adduser deploy          # crée le compte, son home, et demande le mot de passe
sudo usermod -aG sudo deploy # l'ajoute AU groupe sudo (le -a est vital)

🧠 Quiz de révision

Chapitre suivant : sudo & moindre privilège — comment sortir de root pour de bon et administrer sans danger.