Gérer utilisateurs, groupes et permissions sur RHEL 10

Sur Red Hat Enterprise Linux 10, la gestion des utilisateurs et des permissions reste l’épine dorsale de l’administration. L’examen RHCSA évalue systématiquement la création d’utilisateurs, le contrôle fin des accès aux fichiers, l’usage correct de sudo et la maîtrise des bits spéciaux. Ce tutoriel pratique se concentre sur les commandes que le candidat exécutera réellement le jour J et sur les vérifications à enchaîner pour s’assurer qu’une configuration tient.

Prérequis avant de commencer

• Un système RHEL 10, Rocky Linux 10 ou AlmaLinux 10 fraîchement installé.
• Un compte avec privilèges sudo ou un accès root direct.
• Familiarité avec un éditeur de texte ligne de commande, vim ou nano.
• Niveau attendu : débutant à intermédiaire. Temps estimé : 90 minutes pour parcourir la totalité des étapes avec exercices.

Étape 1 — Comprendre les fichiers de référence

Avant d’exécuter la moindre commande de création, il faut savoir où Linux stocke les comptes. Trois fichiers texte sous /etc contiennent toute l’information utilisateur du système, et toutes les commandes useradd ou passwd ne font que les modifier de manière contrôlée. Comprendre leur structure permet de diagnostiquer immédiatement un compte qui se comporte mal.

cat /etc/passwd | head -5
sudo cat /etc/shadow | head -5
cat /etc/group | head -5

Le fichier /etc/passwd liste un utilisateur par ligne au format nom:x:UID:GID:commentaire:home:shell. Le x en deuxième colonne signifie que le hash du mot de passe est stocké séparément dans /etc/shadow, lisible uniquement par root. Le fichier /etc/group liste les groupes avec leurs membres secondaires. Cette séparation entre /etc/passwd lisible par tous et /etc/shadow protégé est une protection fondamentale héritée de la fin des années 1980, qu’aucun administrateur ne doit contourner.

Étape 2 — Créer un utilisateur avec useradd

La commande useradd de RHEL 10 crée un utilisateur, son groupe primaire de même nom, son répertoire personnel sous /home et copie les fichiers de /etc/skel. Plusieurs options critiques distinguent un compte propre d’un compte mal configuré.

sudo useradd -m -s /bin/bash -c "Awa Diop, comptable" awa
sudo passwd awa

L’option -m garantit la création du home ; sans elle sur certaines distributions dérivées, l’utilisateur n’a pas de répertoire et la connexion échoue silencieusement. L’option -s fixe le shell par défaut ; /sbin/nologin au lieu de /bin/bash bloque la connexion interactive — utile pour les comptes de service. La commande passwd définit le mot de passe en interactif ; sur RHCSA, oublier cette étape revient à créer un compte verrouillé qui ne sert à rien.

Pour créer plusieurs utilisateurs en une seule passe, par exemple lors d’un exercice, on enchaîne avec une boucle Bash :

for u in alice bob carol; do
    sudo useradd -m -s /bin/bash "$u"
    echo "$u:Pass2026!" | sudo chpasswd
done

La commande chpasswd accepte le format utilisateur:motdepasse sur l’entrée standard, ce qui permet de scripter la création initiale d’un lot. Pour de la production, on remplacerait évidemment le mot de passe statique par un mécanisme aléatoire, mais pour un exercice RHCSA, cette syntaxe gagne un temps précieux.

Étape 3 — Modifier un utilisateur existant

La commande usermod couvre les ajustements après création : changer le shell, déplacer le home, ajouter à un groupe secondaire, verrouiller un compte. Trois usages dominent les sujets RHCSA.

sudo usermod -aG wheel awa            # Ajout au groupe wheel (sudoers)
sudo usermod -L bob                    # Verrouille le compte
sudo usermod -e 2027-12-31 carol       # Date d'expiration

L’option -aG est cruciale : -a signifie append. Si l’on omet le -a et que l’on utilise -G seul, on remplace tous les groupes secondaires de l’utilisateur par celui indiqué — c’est la cause numéro un de la perte d’accès sudo en cours d’exercice. Le verrouillage par -L ajoute un point d’exclamation devant le hash dans /etc/shadow, ce que l’on vérifie immédiatement avec sudo passwd -S bob.

Étape 4 — Gérer les groupes

Les commandes groupadd, groupmod et groupdel manipulent /etc/group. Un groupe peut servir à partager un répertoire entre plusieurs utilisateurs, ce qui revient régulièrement dans les sujets EX200.

sudo groupadd -g 5000 compta
sudo usermod -aG compta awa
sudo usermod -aG compta bob
getent group compta

L’option -g fixe explicitement le GID, utile pour aligner les groupes entre plusieurs serveurs partageant un home NFS. La commande getent group compta interroge la base unifiée des groupes (locale plus LDAP éventuel) et confirme la présence des deux utilisateurs en seconde ligne. Si le groupe n’apparaît pas, la création a échoué silencieusement — souvent à cause d’un GID déjà utilisé.

Étape 5 — Maîtriser les permissions rwx standard

Chaque fichier et répertoire Linux porte trois ensembles de permissions : utilisateur propriétaire, groupe propriétaire, autres. La commande ls -l les affiche en notation symbolique sur dix caractères. La maîtrise des deux écritures, octale et symbolique, est non négociable pour RHCSA.

touch /tmp/exemple.txt
ls -l /tmp/exemple.txt
chmod 640 /tmp/exemple.txt
chmod g+x,o-r /tmp/exemple.txt
ls -l /tmp/exemple.txt

La sortie initiale affiche -rw-r--r--, soit l’octal 644. Après chmod 640, la sortie devient -rw-r----- : l’utilisateur lit et écrit, le groupe lit, les autres n’ont rien. La syntaxe symbolique g+x,o-r ajoute l’exécution au groupe et retire la lecture aux autres, ce qui ne change ici rien aux permissions des autres mais ajoute le bit x au groupe. Sur RHCSA, savoir basculer entre les deux notations en une fraction de seconde fait la différence entre une tâche réussie et une tâche partielle.

Étape 6 — SUID, SGID et sticky bit

Au-dessus du triplet rwx, trois bits spéciaux modifient le comportement. SUID (set-user-ID, octal 4000) fait s’exécuter un programme avec les droits du propriétaire au lieu de l’appelant — c’est ainsi que passwd peut écrire dans /etc/shadow alors qu’il est lancé par un utilisateur ordinaire. SGID (set-group-ID, octal 2000) joue le même rôle pour le groupe, et appliqué à un répertoire force tout fichier créé à hériter du groupe propriétaire du répertoire. Le sticky bit (octal 1000) appliqué à un répertoire empêche un utilisateur de supprimer les fichiers qu’il ne possède pas — c’est le mécanisme qui protège /tmp.

ls -ld /tmp                            # affiche drwxrwxrwt
ls -l /usr/bin/passwd                  # affiche -rwsr-xr-x

# Création d'un répertoire partagé compta avec SGID
sudo mkdir /srv/compta
sudo chown root:compta /srv/compta
sudo chmod 2770 /srv/compta
ls -ld /srv/compta

Le t minuscule en dernière position de /tmp signale le sticky bit ; le s en quatrième position de passwd signale SUID. Le mode 2770 du répertoire compta combine SGID (2000) avec rwxrwx--- (770). Tout fichier créé désormais dans /srv/compta appartiendra automatiquement au groupe compta, ce qui élimine les déboires habituels du partage en équipe.

Étape 7 — Les ACL POSIX

Quand le triplet rwx ne suffit pas — par exemple pour donner accès en lecture à un utilisateur ponctuel sans modifier les groupes — on bascule sur les ACL POSIX, supportées nativement par XFS et ext4 sur RHEL 10. Les commandes getfacl et setfacl manipulent ces listes étendues.

setfacl -m u:carol:r-x /srv/compta
getfacl /srv/compta
ls -l /srv | grep compta

La sortie de getfacl liste les permissions étendues sous la forme user:carol:r-x. Le + qui apparaît à la fin du mode dans ls -l signale qu’une ACL est appliquée. Pour retirer une entrée précise, on utilise setfacl -x u:carol ; pour effacer toutes les ACL non standard, setfacl -b. Les ACL constituent la solution propre pour les cas particuliers, et apparaissent fréquemment dans les sujets EX200 sous des formulations comme « donner à utilisateur X uniquement le droit de lire ».

Étape 8 — Politique de mot de passe avec chage

La commande chage manipule les attributs d’expiration du mot de passe stockés dans /etc/shadow. Le sujet revient régulièrement à l’examen sous des formulations comme « le mot de passe doit expirer dans 90 jours » ou « avertir l’utilisateur 7 jours avant expiration ».

sudo chage -l awa
sudo chage -M 90 -W 7 -m 1 awa
sudo chage -l awa

L’option -M définit la durée maximale de validité du mot de passe en jours, -W le nombre de jours d’avertissement avant expiration, -m le minimum entre deux changements pour empêcher un utilisateur de changer trois fois d’affilée pour revenir à l’original. La commande chage -d 0 force le changement de mot de passe à la prochaine connexion, technique classique pour distribuer un mot de passe initial et obliger l’utilisateur à le redéfinir.

Étape 9 — Déléguer avec sudo

L’élévation contrôlée des privilèges passe par sudo. Le fichier /etc/sudoers ne se modifie jamais directement avec un éditeur banal — toujours via visudo qui valide la syntaxe avant écriture. La pratique recommandée consiste à créer des fichiers séparés sous /etc/sudoers.d/ pour isoler les règles personnalisées.

sudo visudo -f /etc/sudoers.d/awa
# Contenu :
awa ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart httpd
sudo visudo -c

Cette règle autorise awa à redémarrer Apache sans saisir son mot de passe, mais pour cette commande exacte uniquement. La commande visudo -c vérifie la syntaxe globale après modification — toujours l’exécuter avant de quitter une session, parce qu’une erreur de syntaxe casse sudo sur tout le système. Le groupe wheel, configuré par défaut dans /etc/sudoers, donne à ses membres tous les pouvoirs sudo avec mot de passe ; c’est pour cela que l’on ajoute les administrateurs à ce groupe avec usermod -aG wheel.

Étape 10 — Vérifier la configuration

Une session de configuration ne se termine jamais sans validation explicite. Cinq commandes confirment qu’utilisateur, groupes, permissions et délégation sont cohérents.

id awa                                  # UID, GID primaire, groupes secondaires
sudo passwd -S awa                       # Statut du compte (PS pour password set)
groups awa                               # Liste des groupes en notation lisible
getfacl /srv/compta | head -20           # Vérifie les ACL
sudo -lU awa                             # Liste les commandes sudo autorisées

La sortie id awa doit montrer l’UID attendu et la liste complète des groupes. passwd -S awa retourne PS pour Password Set ; toute autre valeur (L, NP) signale un problème. sudo -lU awa liste toutes les règles sudo qui s’appliquent — utile quand on a oublié à quel sudoers.d on a ajouté quoi.

Erreurs fréquentes

Adaptation aux environnements multi-utilisateurs limités

Sur des serveurs partagés à faible RAM — typiquement 2 Go — il vaut mieux configurer un nombre raisonnable d’utilisateurs simultanés et fixer une limite stricte avec ulimit ou limits.conf pour éviter qu’un utilisateur saturant le swap n’embarque tout le serveur. Le fichier /etc/security/limits.d/20-nproc.conf définit le nombre maximum de processus par utilisateur ; pour un serveur d’entraînement RHCSA partagé entre plusieurs candidats, fixer une valeur autour de 200 par utilisateur reste un bon compromis entre confort d’usage et protection contre les fork bombs accidentelles.

Tutoriels frères

• Installer Red Hat Enterprise Linux 10 pas à pas
• SELinux pas à pas sur RHEL 10 pour RHCSA

Pour explorer plus loin

• 🔝 Retour à l’article principal : RHCSA EX200 v10 : la voie d’entrée Linux entreprise
• Documentation officielle : Managing users and groups RHEL 10
• Documentation officielle : Managing file permissions RHEL 10

Questions fréquentes

Quelle différence entre groupe primaire et groupe secondaire ?

Le groupe primaire d’un utilisateur, défini dans /etc/passwd, devient le groupe propriétaire des fichiers que cet utilisateur crée. Les groupes secondaires, définis dans /etc/group, donnent accès à des ressources mais ne s’appliquent pas par défaut aux nouveaux fichiers — sauf si le répertoire parent porte le SGID.

Faut-il préférer visudo ou éditer directement /etc/sudoers.d/ ?

Toujours visudo, y compris pour les fichiers dans /etc/sudoers.d/, parce que visudo -f chemin valide la syntaxe avant écriture. Une faute de frappe non détectée casse sudo sur tout le système jusqu’au prochain reboot en rescue.

Le mot de passe root doit-il être différent du mien ?

Oui. Le compte root et le compte personnel administrateur ont des rôles différents. La pratique standard désactive même la connexion SSH directe en root et impose le passage par un utilisateur du groupe wheel. Sur RHEL 10, la directive PermitRootLogin de /etc/ssh/sshd_config vaut par défaut prohibit-password, ce qui autorise la connexion root uniquement par clé SSH et refuse l’authentification par mot de passe. Pour bloquer entièrement la connexion root, on bascule explicitement sur PermitRootLogin no.

Comment lister tous les utilisateurs réels du système ?

La commande getent passwd | awk -F: '$3>=1000 {print $1}' filtre les comptes avec UID supérieur ou égal à 1000, ce qui correspond aux utilisateurs créés par administration et exclut les comptes de service système.

Comment supprimer proprement un utilisateur ?

La commande userdel -r awa supprime le compte et son répertoire personnel. Sans -r, le home est conservé, ce qui peut être souhaité si l’on veut transférer les données. Pour un nettoyage complet, vérifier ensuite avec find / -uid 1003 2>/dev/null qu’aucun fichier orphelin ne reste sur le système.

Les ACL ralentissent-elles les opérations sur les fichiers ?

Sur XFS et ext4, les ACL sont stockées dans des attributs étendus et n’introduisent pas de surcoût mesurable pour les opérations courantes. La pénalité reste théorique sauf sur des charges I/O massives avec des milliers d’entrées ACL par fichier, configuration que l’on ne rencontre jamais en pratique.