2.3 Gestion des utilisateurs et groupes¶

Lorsqu'un compte partagé devient la solution par défaut aux problèmes d’accès, il ne s’agit pas seulement d’une mauvaise pratique, mais d’une faille de sécurité structurelle.

Les comptes partagés empêchent toute traçabilité, rendent impossible une gestion des accès et permettent de contourner les mécanismes de sécurité du système.

La mise en place de comptes nominatifs et de groupes adaptés sont indispensables pour représenter correctement : 1) l’organisation de l’entreprise 2) assurer une administration fiable et sécurisée du système.

2.3.1 Introduction¶

Dans un système Unix/Linux, un compte utilisateur n’est pas seulement un nom : il correspond à un identifiant numérique unique, appelé UID (User ID).
De même, chaque groupe possède un identifiant numérique, le GID (Group ID).
Ces identifiants permettent au noyau de différencier les comptes et de structurer leurs accès.

« Every process has a set of associated numeric user identifiers (UIDs) and group identifiers (GIDs). »

Cela signifie qu’au moment où un utilisateur lance un programme, le processus hérite de l’UID et du GID du compte qui l’exécute.

Pourquoi est-ce indispensable à comprendre pour gérer les utilisateurs ?
Parce que ces identifiants (UID/GID) sont les informations que le noyau utilisera plus tard pour vérifier si un processus est autorisé ou non à accéder à un fichier ou à une ressource.

Ce mécanisme est à la base du fonctionnement du modèle de permissions POSIX utilisé par toutes les distributions Linux.

2.3.2 Les fichiers systèmes liés aux utilisateurs¶

Pour fonctionner, la gestion des comptes s’appuie sur plusieurs fichiers de configuration. Ils ne doivent jamais être modifiés à la main dans un environnement de production, mais il est indispensable d’en connaître le rôle.

Fichier /etc/passwd Ce fichier répertorie l’ensemble des comptes du système (comptes utilisateur et comptes système).
Pour chaque compte, il indique : - le nom du compte ; - son UID (User ID) ; - son GID principal (Group ID) ; - son dossier personnel ; - son shell de connexion.

Afficher le fichier /etc/passwd

cat /etc/passwd

Vous devriez obtenir quelque chose comme ceci:

/home/etudiant # cat /etc/passwd
root:x:0:0:root:/root:/bin/sh
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/mail:/sbin/nologin
news:x:9:13:news:/usr/lib/news:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin
cron:x:16:16:cron:/var/spool/cron:/sbin/nologin
ftp:x:21:21::/var/lib/ftp:/sbin/nologin
sshd:x:22:22:sshd:/dev/null:/sbin/nologin
games:x:35:35:games:/usr/games:/sbin/nologin
ntp:x:123:123:NTP:/var/empty:/sbin/nologin
guest:x:405:100:guest:/dev/null:/sbin/nologin
nobody:x:65534:65534:nobody:/:/sbin/nologin
klogd:x:100:101:klogd:/dev/null:/sbin/nologin
etudiant:x:1000:1000::/home/etudiant:/bin/sh

On retrouve bien notre utilisateur étudiant.

etudiant:x:1000:1000::/home/etudiant:/bin/sh

Pour Alpine Linux (comme toutes les distros Unix), la signification des champs est la même :

	Champ	Signification
etudiant	login	nom du compte
x	mot de passe	stocké dans /etc/shadow
1000	UID	identifiant utilisateur du compte
1000	GID	identifiant de groupe principal
vide	info	champ “gecos” (description facultative)
/home/etudiant	home	emplacement du dossier personnel
/bin/sh	shell	programme lancé automatiquement à la connexion
Fichier/etc/shadow
Ce fichier contient les empreintes de mots de passe (hachées).
Il est strictement réservé au système et n’est lisible que par root.

Fichier /etc/group Ce fichier répertorie tous les groupes du système. Pour chaque groupe, il indique : - le nom du group; - son GID (Group ID) ; - la liste des membres faisant partie de ce groupe.

cat /etc/group

Remarquez la ligne concernant le groupe wheel

 wheel:x:10:root,etudiant

Rappelez-vous nous avons ajouté l'utilisateur etudiant au groupe wheel pour qu'il soit autorisé à utilisé la commande sudo. C'est pour cela que nous voyons l'utilisateur etudiant figuré dans la liste des menbres de wheel.

2.3.2 Travaux dirigés¶

2.3.2.1 Création des utilisateurs¶

Pour créer un utilisateur la commande est adduser (busybox). Commençons par afficher les options disponible de cette commande, tapez adduser --help

/home/etudiant #  adduser --help
BusyBox v1.37.0 (2025-08-05 16:40:33 UTC) multi-call binary.

Usage: adduser [OPTIONS] USER [GROUP]

Create new user, or add USER to GROUP

    -h DIR      Home directory
    -g GECOS    GECOS field
    -s SHELL    Login shell
    -G GRP      Group
    -S      Create a system user
    -D      Don't assign a password
    -H      Don't create home directory
    -u UID      User id
    -k SKEL     Skeleton directory (/etc/skel)

Pour ce travail on va mettre simuler la mise en place d’une petite équipe de travail avec 5 comptes.

Compte	Rôle	Exigence
alice	développeuse	home standard
bob	administrateur junior	doit être ajouté à wheel + home personnalisé
invite	invité temporaire	pas de shell, pas de mot de passe
serviceapp	service interne	compte système, pas de home
stagiaire	compte mal configuré volontairement	à diagnostiquer et réparer
## **PARTIE 1 — Création et observation

1) Créer le compte alice¶

adduser alice

Vérifications¶

• UID, GID, home, shell : grep alice /etc/passwd id alice

2) Créer le compte bob¶

Étape 1 — Créer bob avec un home sur un stockage séparé¶

adduser -h /data/bob bob

Étape 2 — Donner les droits administrateur (wheel)¶

adduser bob wheel

Étape 3 — Forcer un shell différent¶

adduser -s /bin/ash bob

Vérifications¶

• bob est dans wheel ? id bob
• bob a un shell différent ? grep bob /etc/passwd
• bob possède bien /data/bob ? ls -ld /data/bob

3) Créer invite, un compte temporaire bloqué par défaut¶

adduser -D -h /tmp/invite -s /sbin/nologin invite

Vérifications¶

• se connecter → échec normal su - invite This account is not available: raison de l’échec → nologin

4) Créer serviceapp, un vrai compte de service¶

adduser -S -H serviceapp

Vérifications¶

id serviceapp
grep serviceapp /etc/passwd

5) Créer stagiaire, mais avec des erreurs volontaires¶

Maintenant on va crée un compte mal paramétré. A vous de diagnostiquer le problème et de le réparer: Pour commencer, copier/coller cette commande

adduser -H -D -s /sbin/nologin stagiaire

Travail demandé : corriger le compte¶

1. Doit posséder son répertoire personnel dans /home/stagiaire :
2. Son shell doit être sh
3. Posséder un mode passe

Le répertoire skeleton (/etc/skel)¶

Lorsqu’un utilisateur est créé sous Alpine Linux, son répertoire personnel est presque entièrement vide. Il ne contient que les éléments générés automatiquement par les outils système (comme .ash_history lorsque le shell BusyBox ash démarre pour la première fois).

Alpine ne fournit aucun fichier de configuration par défaut : pas de .profile, pas de structure de travail, aucune personnalisation.
C’est à l’administrateur de décider ce qui doit exister dans chaque nouvel espace utilisateur.
Pour cela, il peut utiliser le répertoire /etc/skel, dont le contenu sera copié dans chaque nouveau HOME — uniquement si l’administrateur le renseigne.

L’administrateur peut remplir /etc/skel pour préparer : - une structure de dossiers, - des fichiers de configuration, - un message d’accueil, - ou tout autre élément commun.

Tout ce qui se trouve dans /etc/skel sera copié tel quel pour chaque création d’un utilisateur avec adduser.

On va préparer des dossiers standard pour rendre l’environnement plus intuitif pour des utilisateurs habitués à Windows :

mkdir -p /etc/skel/Documents
mkdir -p /etc/skel/Images
mkdir -p /etc/skel/Téléchargements
mkdir -p /etc/skel/Vidéos
mkdir -p /etc/skel/Musique

On vérifie : ls /etc/skel

Lors de la création d’un nouvel utilisateur, ces dossiers apparaîtront automatiquement dans son HOME.

On peut également ajouter un fichier .profile: Le fichier .profile est un script exécuté automatiquement à chaque ouverture de session utilisateur . Ce fichier permet : - d’exécuter des commandes à chaque connexion, - de configurer le shell, - de définir des paramètres,

Placée dans /etc/skel, la version modèle de .profile est copiée dans le HOME de chaque nouvel utilisateur. Cela permet de standardiser automatiquement l’environnement et la configuration de tous les comptes créés.

Voici un fichier /etc/skel/.profile (Copier/coller). Il ne fait pas grand chois à part dire "Bienvenue" à chaque nouvel utilisateur.

cat > /etc/skel/.profile << 'EOF'
echo "----------------------------------------"
echo "Bienvenue sur votre espace personnel !"
echo "Vos dossiers Documents, Images, etc. sont prêts."
echo "Bonne prise en main de votre environnement Alpine."
echo "----------------------------------------"
EOF

Maintenant créons un nouvelle utilisateur:

adduser -k /etc/skel-projet clara

Un petit test

su - clara

Changer d’utilisateur avec su¶

Il arrive qu’un administrateur doive agir « à la place » d’un autre utilisateur sans fermer sa propre session : tester ses droits, accéder à son environnement, ou exécuter une commande sous son identité.
La commande su sert précisément à cela.

Quand on tape su clara, on demande au système de changer l’identité utilisée par le shell courant. Techniquement, le processus reste le même, mais son UID/GID effectifs deviennent ceux de clara. On agit donc comme clara, mais dans le shell de départ. Son environnement n’est pas rechargé : on garde le même répertoire courant, les mêmes variables, et aucun fichier de configuration de clara n’est exécuté.

Pour vérifier ce comportement, on peut observer :

pwd          # répertoire de travail actuel
su clara     # Changement d'identité
id           # Afficje l'UID de clara
pwd          # inchangé

Et donc pas de message de bienvenue.

À l’inverse, su - clara demande l’ouverture d’une nouvelle session, comme si clara venait de se connecter normalement.

On obtient bien cette fois-ci notre message de bienvenue. Un nouveau shell a été lancé : le répertoire courant devient /home/alice, ses fichiers de configuration sont exécutés et son environnement est reconstruit.

su - clara
id           # identité de clara
pwd          # /home/clara

En bref :
su clara → on change d’identité dans le même shell.su - clara → on ouvre une vraie session pour clara.

---

Auteur : J-F Ornech Formation : BTS SIO – SISR
Établissement : Lycée Merleau-Ponty Année : 2025–2026

---