Utilisateurs Linux, Groupes et Permissions : Un Flux de Travail d’Intégration Pratique

The Monday-Morning Access Request

Lundi matin, un nouveau coéquipier rejoint votre projet et a besoin d’accès à l’espace de travail de développement partagé sur votre Ubuntu VPS aujourd’hui. Il devrait pouvoir se connecter, ouvrir le répertoire d’équipe et faire un travail normal sans attendre quelqu’un d’autre pour chaque petite tâche. Il ne devrait pas obtenir l’accès root. Il devrait également rester en dehors de la zone restreinte release-secret.

C’est là que les utilisateurs, groupes et permissions Linux cessent de ressembler à trois sujets de manuel séparés et commencent à agir comme un système pratique. Peut-être que le serveur vit sur un VPS AlexHost, peut-être qu’il vit ailleurs, mais la question d’accès est la même partout : comment donnez-vous un accès utile sans donner le contrôle total ?

Cette procédure pas à pas suit cette seule demande d’intégration du début à la fin, donc chaque commande a un travail clair et une place dans l’histoire. Si des termes comme utilisateur, groupe et permission ont jamais semblé flous par eux-mêmes, c’est le moyen le plus facile de les faire fonctionner ensemble.

Workflow:
user account → group membership → ownership alignment → permissions → verification

Un modèle mental avant toute commande

Avant toute commande, gardez une analogie en tête : pensez au serveur comme à un immeuble de bureaux. Un utilisateur est le badge nominatif d’une personne. Un groupe est le département auquel il appartient. Les permissions sont les règles d’accès aux portes des salles et des armoires. L’accès Linux devient beaucoup plus facile une fois que vous le lisez de cette façon au lieu de mémoriser des commandes isolées.

Les trois questions fondamentales sont simples :

• Un utilisateur répond à « Qui est-ce ? »
• Un groupe répond à « À quelle équipe partagée appartient-il ? »
• Les permissions répondent à « Que peut-il faire ici ? »

C’est aussi le cœur du principe du moindre privilège : donner à quelqu’un exactement assez d’accès pour faire son travail, et rien de plus. Les permissions seules ne résoudront jamais le problème entièrement, car la bonne règle sur la mauvaise identité ou la mauvaise équipe produit toujours le mauvais résultat.

La même logique s’applique à chaque fichier et répertoire. Linux vérifie d’abord si vous êtes le propriétaire, si vous correspondez au groupe du chemin, ou si vous entrez dans la catégorie others — c’est-à-dire tous les autres sur la machine. Ce n’est qu’ensuite qu’il applique la règle pertinente. C’est pourquoi le même chemin peut se comporter différemment pour différents utilisateurs.

Le tableau de traduction compact ci-dessous suffit pour le reste de cet article :

📝 Note : Les commandes ci-dessous utilisent des exemples adaptés à Ubuntu, mais le modèle mental lui-même s’applique à Linux en général.

À partir de là, la première étape devient évidente : avant que Maya puisse partager quoi que ce soit avec l’équipe, le système doit savoir qu’elle existe en tant que personne à part entière.

Étape 1 : Créer la personne sur le système

Un compte utilisateur Linux n’est pas juste un label dans une liste. Il donne à Maya une identité de connexion, un répertoire personnel et un contexte de travail séparé de tous les autres sur le serveur. Cette séparation est ce qui rend la responsabilité possible. Si quelque chose change, vous pouvez dire qui l’a changé. Si l’accès doit rester limité, vous pouvez le limiter à un seul compte réel au lieu d’une connexion partagée mystérieuse.

Sur Ubuntu, la façon conviviale de créer ce compte est :

sudo adduser maya

Ubuntu vous guidera dans la configuration normale et créera généralement /home/maya en même temps. Vous pouvez également voir useradd dans des scripts ou de la documentation de bas niveau. Sur les systèmes Debian/Ubuntu, adduser est généralement le meilleur choix pour un compte utilisateur normal.

C’est aussi pourquoi les comptes partagés sont une si mauvaise habitude. Si plusieurs personnes se connectent toutes en tant que même utilisateur — ou pire, « utiliser simplement root » — vous perdez la traçabilité immédiatement, et chaque décision de permission ultérieure devient plus bâclée. Un compte utilisateur répond à qui est Maya. Il ne répond pas encore à quel espace de projet partagé elle peut utiliser.

Étape 2 : Les Mettre dans la Bonne Équipe

Maintenant Maya existe, mais elle n’a toujours aucune relation avec l’espace de travail partagé. C’est là que les groupes deviennent utiles. Un groupe principal suit le compte par défaut. Les groupes supplémentaires sont les équipes supplémentaires que vous attachez à un utilisateur pour que l’accès partagé s’étende proprement sur plusieurs personnes et plusieurs projets.

Si votre groupe de projet n’existe pas déjà, créez-le d’abord. Ensuite, ajoutez Maya à ce groupe au lieu de remplacer ses appartenances supplémentaires existantes.

⚠️ Avertissement : usermod -G devteam maya sans -a peut remplacer les groupes supplémentaires existants de Maya. Le drapeau -a signifie « ajouter », et c’est la partie qui rend cela sûr.

Utilisez les commandes suivantes pour créer le groupe et vérifier que Maya en fait partie :

sudo groupadd devteam
sudo usermod -aG devteam maya
id maya

Si devteam existe déjà, ignorez la ligne groupadd. Dans la sortie id, vous voulez voir devteam listé parmi les groupes de Maya :

Cette sortie prouve que l’appartenance à l’équipe est là. Elle ne prouve pas encore que Maya peut utiliser l’espace de travail. Être dans devteam ne fait toujours rien si le répertoire lui-même est possédé et groupé d’une manière qui ignore cette équipe.

Étape 3 : Aligner la propriété avec l’espace de travail

C’est le maillon manquant derrière beaucoup de frustrations des débutants. La question suivante concerne l’espace de travail lui-même : qui le possède et quel groupe y est attaché ? Tant que cela n’est pas aligné, l’adhésion correcte de Maya à l’équipe n’a nulle part où s’appliquer utilement.

Pour cette procédure pas à pas, utilisez un chemin partagé et un chemin restreint. La zone d’équipe partagée sera /srv/devworkspace. La zone privée sera /srv/release-secrets, avec un exemple de fichier à l’intérieur. Créez d’abord les deux chemins :

sudo mkdir -p /srv/devworkspace /srv/release-secrets
sudo touch /srv/release-secrets/deploy-key.txt

Ensuite, inspectez à quoi ressemblent actuellement ces chemins :

ls -ld /srv/devworkspace /srv/release-secrets
ls -l /srv/release-secrets/deploy-key.txt

Le -d est important ici car il indique à ls de décrire le répertoire lui-même au lieu de lister son contenu. Dans la liste longue, commencez par trois éléments. Regardez d’abord la chaîne de permissions à gauche. Ensuite, vérifiez le propriétaire et le groupe. Si les deux chemins affichent toujours root root, l’adhésion de Maya au nouveau groupe devteam n’a rien d’utile auquel se connecter pour le moment.

Si vous aviez seulement besoin de changer le groupe, chgrp devteam /srv/devworkspace ferait cela. Ici, chown owner:group est plus clair car il définit la cible complète en une seule ligne. L’espace de travail partagé devrait appartenir à root:devteam, tandis que le chemin restreint devrait rester root:root :

sudo chown root:devteam /srv/devworkspace
sudo chown root:root /srv/release-secrets /srv/release-secrets/deploy-key.txt

Après cet alignement de propriété, les parties importantes de la liste devraient se lire comme suit :

drwxr-xr-x  root devteam  /srv/devworkspace
drwxr-xr-x  root root     /srv/release-secrets
-rw-r--r--  root root     /srv/release-secrets/deploy-key.txt

permissions  owner  group

💡 Conseil : Gardez les secrets restreints en dehors de l’espace de travail accessible en écriture par le groupe. Cela rend la configuration facile à comprendre et évite les cas limites désordonnés d’écriture de répertoire qui ne sont pas utiles dans un flux d’intégration pour débutants.

À ce stade, la propriété indique à Linux à quel domaine chaque chemin est attaché. L’étape finale consiste à définir ce que ce propriétaire, ce groupe et tous les autres peuvent réellement faire là.

Étape 4 : Définir les permissions qui correspondent au travail

Avec la propriété alignée, vous pouvez maintenant définir la règle réelle pour chaque chemin : qui peut le lire, le modifier ou y accéder. Pensez au travail d’abord, aux chiffres ensuite. Vous n’essayez pas de mémoriser tout l’univers des permissions ici ; vous exprimez une règle pratique pour un espace de travail partagé et une zone secrète restreinte.

La petite matrice ci-dessous est la seule dont la plupart des débutants ont besoin :

La ligne du répertoire est le piège. Sur un répertoire, x ne signifie pas « exécuter le dossier ». Cela signifie que vous pouvez entrer ce chemin ou le traverser en allant vers quelque chose de plus profond. C’est pourquoi un fichier peut sembler lisible en théorie et échouer quand même en pratique si vous ne pouvez pas traverser le chemin du répertoire qui y mène.

Appliquez maintenant les règles qui correspondent à cette histoire d’intégration. L’espace de travail d’équipe doit être utilisable par root et devteam, mais fermé à tous les autres. Le répertoire secret doit rester réservé à root, et le fichier secret à l’intérieur doit rester lisible par root uniquement :

sudo chmod 770 /srv/devworkspace
sudo chmod 700 /srv/release-secrets
sudo chmod 600 /srv/release-secrets/deploy-key.txt

Ces chiffres sont plus faciles qu’ils ne le paraissent au premier abord quand vous les attachez au travail. 770 sur /srv/devworkspace signifie que root a un accès complet, et devteam obtient le même accès partagé. Tous les autres n’obtiennent rien là-bas. 700 sur /srv/release-secrets signifie que seul root peut même entrer dans ce répertoire. 600 sur deploy-key.txt signifie que seul root peut lire ou modifier le fichier. L’important n’est pas l’arithmétique. C’est que chaque mode reflète une décision que vous avez déjà prise concernant ce chemin.

drwxrwx---  root devteam  /srv/devworkspace
drwx------  root root     /srv/release-secrets
-rw-------  root root     /srv/release-secrets/deploy-key.txt

⚠️ Avertissement : chmod 777 n’est pas un vrai correctif. Cela signifie généralement que la propriété ou la conception du chemin est incorrecte, donc quelqu’un applique des permissions grand ouvert par-dessus l’erreur au lieu de corriger la conception d’accès réelle.

Une note avancée, volontairement brève : dans les répertoires partagés plus actifs, les administrateurs utilisent parfois le comportement setgid du répertoire pour que les fichiers nouvellement créés héritent automatiquement du groupe d’équipe. C’est utile plus tard, mais cela appartient à un article de suivi. Pour ce flux de travail, les utilisateurs simples, les groupes, la propriété et les règles rwx de base suffisent.

Étape 5 : Vérifier l’accès et les limites

La configuration n’est que la moitié du travail. Un bon onboarding Linux teste également la limite. La condition de succès n’est pas seulement « Maya peut faire quelque chose ». C’est « Maya peut faire le travail prévu et ne peut toujours pas accéder au chemin restreint ».

Démarrez un nouveau contexte de connexion pour Maya, puis testez une action autorisée et une action refusée :

su - maya
cd /srv/devworkspace
touch first-day-check.txt
ls -l /srv/devworkspace

Ensuite, testez la limite :

cd /srv/release-secrets
cat /srv/release-secrets/deploy-key.txt

Le test de l’espace de travail devrait fonctionner. Maya devrait pouvoir accéder à /srv/devworkspace et créer un fichier simple là-bas. Le test de limite devrait échouer avec une erreur de permission, et cet échec est le signal de succès. Le principe du moindre privilège est censé avoir des limites.

💡 Conseil : Si Maya ne peut toujours pas utiliser /srv/devworkspace même si les commandes semblent correctes, ouvrez une nouvelle session de connexion et testez à nouveau. L’appartenance au groupe supplémentaire n’apparaît pas toujours de manière cohérente dans les anciens shells.

C’est la façon calme de vérifier l’onboarding : confirmez le chemin heureux, puis confirmez la limite. Une fois que vous faites les deux, le flux de travail cesse d’être une théorie et devient quelque chose sur lequel vous pouvez compter sur le serveur suivant aussi.

Erreurs courantes qui cassent le modèle

La plupart des confusions sur les permissions Linux ne viennent pas du mystère de Linux. Elles proviennent généralement du même petit ensemble d’erreurs de catégorie. Parfois l’utilisateur est dans la mauvaise équipe. Parfois la propriété du chemin est mauvaise. Parfois le vrai problème est une mauvaise hypothèse sur ce que x signifie, ou un raccourci de permission utilisé à la place d’une conception appropriée.

Le tableau ci-dessous est un moyen pratique de déboguer ce brouillard :

La plupart des problèmes de permission viennent du fait de sauter une couche et de recourir à chmod trop tôt. Une fois que vous savez si le problème est l’identité, l’appartenance à une équipe, la propriété ou la règle du chemin, la solution devient beaucoup plus évidente.

Le résultat pratique

Le contrôle d’accès Linux devient beaucoup plus facile quand vous travaillez dans l’ordre au lieu de traiter les utilisateurs, les groupes et les permissions comme des éléments séparés. Dans cet exemple, Maya a obtenu exactement ce dont elle avait besoin. Elle a une véritable connexion et un accès d’équipe à l’espace de travail partagé. Elle n’a pas accès au chemin release-secret.

Utilisez cette liste de contrôle sur n’importe quel VPS Ubuntu ou petit serveur Linux hébergé :

1. Créer l’identité.
2. Assigner l’équipe partagée.
3. Aligner la propriété du chemin et le groupe.
4. Définir la règle de permission pour ce travail.
5. Tester à la fois l’accès et les limites.

C’est la liste de contrôle réutilisable : identité → équipe → règle, avec l’alignement du chemin au milieu pour que la règle ait réellement un endroit correct où s’appliquer. Si vous voulez approfondir ensuite, les suites naturelles incluent l’accès SSH et sudo. Les modèles de répertoires partagés et la gestion plus large des utilisateurs/groupes Linux s’appuient sur la même base. La logique centrale ne change pas ; vous l’appliquez simplement à des situations plus spécifiques.