Utilisateurs, groupes et droits sous Linux

Chaque commande s’exécute avec une identité. Linux utilise cette identité pour déterminer quels fichiers la commande peut ouvrir et quels paramètres elle peut modifier. Un compte utilisateur peut représenter une personne ou un service qui fonctionne en arrière-plan.

Le numéro derrière le nom

Le noyau identifie un compte par son identifiant utilisateur (UID). Des noms comme alice rendent le numéro plus facile à reconnaître, mais les droits dépendent du numéro. Le compte root a l’UID 0 et son répertoire personnel est /root. Un compte portant un autre nom et l’UID 0 dispose des mêmes pouvoirs de superutilisateur.

Un compte d’utilisateur ordinaire est le compte qu’une personne utilise au quotidien. Sur la plupart des distributions, les UID ordinaires commencent à 1000 ; UID_MIN dans /etc/login.defs définit cette borne. Un utilisateur ordinaire peut modifier ses propres fichiers et tous les autres fichiers auxquels les droits lui donnent accès. La modification de paramètres système protégés nécessite des droits élevés.

Un compte système donne à un service sa propre identité aux droits limités. La plupart ont un UID inférieur à 1000 et un shell comme /usr/sbin/nologin. Le compte spécial nobody a couramment l’UID 65534 : la plage ne suffit donc pas à identifier tous les comptes de service. Debian et Ubuntu utilisent www-data pour les services web ; un service SSH peut utiliser sshd.

Consulte ton identité actuelle

Exécute whoami pour obtenir ton nom d’utilisateur ou id pour obtenir les numéros et les groupes. Par exemple :

uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo),1005(developers)

Lis la sortie en trois parties. L’UID d’Alice est 1001. Son groupe principal est alice, de GID 1001. Sa liste de groupes comprend aussi sudo et developers. C’est une utilisatrice ordinaire, pas root : le groupe sudo peut autoriser des commandes avec des droits élevés, mais son shell courant fonctionne toujours sous l’identité d’Alice.

Beaucoup de shells affichent # pour root et $ pour un utilisateur ordinaire. Une invite peut être personnalisée : consulte donc id lorsque l’identité compte. Le premier compte créé pendant l’installation est souvent un compte ordinaire ayant accès à sudo, notamment sur Ubuntu ; le fait d’avoir été créé en premier n’en fait pas root.

Vérifie les sessions de connexion

Ces commandes répondent à une question différente de whoami : elles indiquent les sessions, et pas seulement l’identité de ton shell. Debian 13 est l’un des systèmes qui utilisent wtmpdb pour cet historique.

Des identités distinctes favorisent le principe du moindre privilège, l’imputabilité et l’isolation. Un service web peut lire les fichiers qu’il sert sans accéder aux documents privés de tous les utilisateurs. Les journaux peuvent indiquer quel compte a agi. Si le service est compromis, l’attaque commence avec les droits de son compte de service. Root peut contourner les restrictions ordinaires de lecture et d’écriture des fichiers ; un deuxième compte avec l’UID 0 représente donc un sérieux problème de sécurité.

Partager un fichier avec une équipe est plus simple lorsque celle-ci dispose d’un groupe. Attribue le fichier à ce groupe, accorde-lui les droits nécessaires et gère ses membres au fil des arrivées et des départs.

Un groupe principal, des appartenances supplémentaires

Un groupe possède un nom et un identifiant de groupe (GID) numérique. Chaque utilisateur possède un groupe principal, enregistré sous forme de GID dans /etc/passwd. Un nouveau fichier prend normalement le groupe principal du processus qui le crée. Plus loin, un répertoire SGID fournira une autre règle d’attribution du groupe d’un nouveau fichier.

Les utilisateurs peuvent aussi avoir plusieurs groupes supplémentaires. Ces appartenances ajoutent des identités de groupe à leurs processus ; l’utilisateur n’a pas besoin de changer de groupe principal chaque fois qu’il ouvre le fichier d’une autre équipe. Linux tient compte à la fois du groupe principal et des groupes supplémentaires pour vérifier si l’utilisateur appartient au groupe d’un fichier.

La plupart des distributions créent un groupe privé d’utilisateur en même temps que chaque utilisateur ordinaire. Alice peut avoir le nom d’utilisateur alice, l’UID 1001, le groupe principal alice et le GID 1001. Les identités utilisateur et de groupe restent distinctes même lorsque leurs noms et leurs numéros correspondent. Un fichier attribué au groupe privé d’Alice n’est pas partagé avec toute l’équipe.

Examine une appartenance à un groupe

Utilise groups pour afficher les noms de tes propres groupes. groups bob et id bob recherchent les appartenances de Bob ; id -Gn affiche les noms des groupes du processus courant sans les numéros. Une recherche de groupe peut afficher :

getent group developers
developers:x:1005:alice,bob

Le groupe s’appelle developers, son GID est 1005 et Alice et Bob figurent comme membres supplémentaires. Un compte dont le GID principal est 1005 appartient aussi au groupe, même si son nom ne figure pas dans cette dernière liste. Pour vérifier toutes les appartenances d’une personne, utilise id avec son nom au lieu de te fier uniquement à cette liste.

Applique les droits d’un groupe

Supposons que plan.txt appartienne à bob:developers et ait le mode rw-r-----. Alice n’est pas Bob, mais elle appartient à developers. Le triplet de droits du milieu, r--, s’applique donc à elle : elle peut lire le plan, mais pas en modifier le contenu. Chen n’est ni l’utilisateur propriétaire ni membre du groupe : le dernier triplet, ---, s’applique donc à lui.

Modifier le nom du groupe associé à un fichier ne crée pas de droits en soi. Si le triplet du groupe est ---, les membres ne reçoivent toujours aucun accès par cette catégorie. Le groupe propriétaire identifie l’équipe ; les bits de droits précisent ce qu’elle peut faire.

Reconnais les groupes aux droits étendus

Certaines appartenances donnent bien plus qu’un accès à un dossier de projet. Debian et Ubuntu autorisent couramment le groupe sudo à exécuter des commandes d’administration ; Fedora et Red Hat Enterprise Linux utilisent couramment wheel. Sur Debian et Ubuntu, adm permet d’accéder à de nombreux journaux système. Le groupe docker contrôle le service Docker et donne de fait un contrôle équivalent à celui de root.

Avant d’ajouter une personne à un groupe, détermine à quoi ce groupe donne accès. Un groupe de projet peut être un moyen restreint de partager du travail, tandis qu’un groupe d’administration peut donner le contrôle de toute la machine.

Linux conserve les informations publiques des comptes séparément des données des mots de passe. Lire l’ordre des champs t’aide à expliquer l’identité d’un compte, sa configuration de connexion et sa politique de mot de passe sans modifier les fichiers à la main.

Lis un enregistrement de compte

/etc/passwd comporte sept champs séparés par des deux-points :

name:password:UID:GID:comment:home:shell
alice:x:1001:1001:Alice Moreau:/home/alice:/bin/bash

L’UID et le GID principal d’Alice sont tous deux 1001. Le commentaire, aussi appelé champ GECOS, indique son nom complet. Son répertoire personnel est /home/alice et son shell de connexion est Bash. Le x renvoie aux données du mot de passe dans /etc/shadow ; il ne signifie pas que son mot de passe est vide.

Les utilisateurs ordinaires peuvent lire /etc/passwd, qui a normalement le mode 644. Les programmes ont besoin de ses informations publiques pour convertir les UID enregistrés en noms. Le stockage des empreintes de mots de passe dans un fichier protégé distinct empêche chaque utilisateur local de les lire.

Lis les données des mots de passe

/etc/shadow comporte neuf champs : nom, empreinte du mot de passe, jour du dernier changement, durée minimale, durée maximale, jours d’avertissement, jours d’inactivité, jour d’expiration du compte et champ réservé. Root peut le lire ; certains systèmes donnent aussi accès au groupe shadow.

Une empreinte de mot de passe est un résultat à sens unique, et non un chiffrement réversible. À la connexion, le système applique la méthode et le sel enregistrés au mot de passe fourni, puis compare le résultat à l’empreinte enregistrée. Un sel aléatoire rend les empreintes différentes même lorsque deux utilisateurs choisissent le même mot de passe. Les enregistrements SHA-512 crypt utilisent $6$salt$hash, éventuellement avec un champ rounds=N ; yescrypt utilise $y$parameters$salt$hash.

Un ! initial verrouille le mot de passe tout en conservant l’empreinte. Un champ contenant seulement !, !! ou * ne possède pas de mot de passe utilisable. D’autres méthodes de connexion, comme les clés SSH, peuvent encore fonctionner lorsque le mot de passe est verrouillé.

Détermine les dates

Examine cet enregistrement dont l’empreinte est abrégée :

alice:$y$j9T$...:20514:0:90:7:::

Les dates comptent les jours écoulés depuis le 1er janvier 1970, UTC. Le jour 20514 correspond au 2 mars 2026. Une durée minimale de 0 permet un changement immédiat du mot de passe ; une durée maximale de 90 entraîne son expiration le 31 mai 2026. L’avertissement de sept jours commence le 24 mai. Les champs vides d’inactivité et d’expiration du compte ne définissent aucune de ces deux limites. Une valeur de dernier changement égale à 0 impose un changement à la prochaine connexion ; une durée maximale de 99999 correspond en pratique à une très longue durée de validité du mot de passe. L’expiration du mot de passe et celle du compte sont deux champs distincts.

Lis les enregistrements de groupes en toute sécurité

/etc/group utilise name:password:GID:members. Dans developers:x:1005:alice,bob, le dernier champ liste les membres supplémentaires. Les membres principaux sont repérés grâce au GID de leurs enregistrements passwd. Le fichier protégé /etc/gshadow stocke les données des mots de passe et des administrateurs de groupes.

Utilise getent passwd alice ou getent group developers pour effectuer des recherches. getent consulte les sources de comptes configurées ainsi que les fichiers locaux. cut -d: -f1,3 /etc/passwd affiche les noms et les UID locaux. Modifie les enregistrements avec des commandes de gestion des comptes comme usermod et passwd ; si une modification directe est inévitable, vipw et vigr verrouillent les fichiers pendant l’opération.

Les tâches d’administration nécessitent davantage d’accès que le travail quotidien. Garde ton shell habituel sous ton propre compte et élève tes privilèges pour l’action qui en a besoin. Les fichiers créés par une commande aux droits élevés peuvent appartenir à root même lorsqu’ils se trouvent dans ton répertoire personnel.

Choisis sudo ou su

Un shell de connexion charge l’environnement de connexion de l’utilisateur cible, y compris son répertoire personnel et ses fichiers de démarrage. Utilise exit pour quitter un shell démarré par su. sudo -i ouvre un shell de connexion root ; sudo -s ouvre un shell root. Ils sont utiles pour une série de tâches d’administration liées, mais chaque commande exécutée dans ce shell dispose de droits élevés jusqu’à ce que tu le quittes.

Sudo vérifie sa politique avant d’exécuter la commande et enregistre la tentative. Les journaux peuvent être envoyés au journal système, à /var/log/auth.log sur les systèmes de la famille Debian ou à /var/log/secure sur ceux de la famille Red Hat. sudo -l affiche les commandes que ton compte peut exécuter. L’autorisation d’utiliser sudo relève d’une décision de la politique, pas du fait de connaître le mot de passe de quelqu’un d’autre.

Comprends l’authentification

Par défaut, sudo demande le mot de passe de l’utilisateur qui l’invoque, pas celui de root. La politique peut modifier ce comportement. Dans le projet sudo en amont, l’horodatage d’authentification dure cinq minutes par défaut ; les paramètres de la distribution peuvent fixer une autre valeur, comme 15 minutes. L’horodatage s’applique normalement dans ce terminal. Exécute sudo -k pour l’invalider lorsque tu as terminé.

Ubuntu démarre normalement sans mot de passe root utilisable et place l’utilisateur créé à l’installation dans sudo. Fedora et les systèmes de la famille Red Hat utilisent couramment wheel. Une tentative refusée peut indiquer que l’utilisateur ne figure pas dans le fichier sudoers ; la tentative est enregistrée.

Confie l’écriture à sudo

Cette commande échoue lorsque ton compte ordinaire ne peut pas écrire dans /etc/hosts :

sudo echo "192.0.2.10 test.local" >> /etc/hosts

Ton shell courant ouvre le fichier pour >> avant que sudo ne s’exécute. Seul echo reçoit les droits de root et echo n’est pas le programme qui ouvre la destination. Confie l’écriture à un processus doté de droits élevés :

echo "192.0.2.10 test.local" | sudo tee -a /etc/hosts

Ici, tee ouvre le fichier protégé en tant que root. Son option -a ajoute le contenu en fin de fichier ; omettre cette option remplacerait le contenu du fichier. Pour une modification interactive, sudoedit /etc/hosts, également écrit sudo -e /etc/hosts, exécute ton éditeur sous ton identité et prend en charge la mise à jour du fichier protégé.

Repère les fichiers de travail appartenant à root

Après sudo mkdir ~/project, examine le résultat avec ls -ld ~/project. Le répertoire se trouve dans ton répertoire personnel, mais il a été créé par root. Ses droits de propriétaire s’appliquent donc à root, tandis que ton compte peut ne disposer que des droits de lecture et d’exécution. Rétablis le propriétaire prévu avec sudo chown alice: ~/project lorsque le projet appartient à Alice. Les deux-points finaux sélectionnent aussi le groupe de connexion d’Alice. La modification et la création ordinaires de fichiers peuvent alors se faire sous le compte d’Alice.

Une règle sudo détermine qui peut exécuter une action, sur quel hôte et sous quelle identité. Accorder à une équipe une action d’administration peut répondre à ses besoins sans lui donner un contrôle sans restriction sur la machine.

Lis les éléments d’une règle

Le modèle de base est who where = (as_whom) what. Par exemple :

alice ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL

La première règle permet à Alice d’exécuter n’importe quelle commande sur n’importe quel hôte en tant que n’importe quel utilisateur et avec n’importe quel groupe. La seconde accorde les mêmes droits au groupe sudo ; % indique un nom de groupe. Une règle courante dans la famille Red Hat est %wheel ALL=(ALL) ALL.

Pour donner tous les droits d’administration à Alice au moyen d’une règle existante de la distribution, exécute sudo usermod -aG sudo alice sur Debian ou Ubuntu, ou utilise wheel sur Fedora et les systèmes apparentés. Alice doit ouvrir une nouvelle session pour que cette appartenance y soit prise en compte. Le -a est important : sans lui, -G remplace ses autres groupes supplémentaires.

Modifie et vérifie la politique

Le fichier principal est /etc/sudoers ; des règles supplémentaires peuvent se trouver dans /etc/sudoers.d/. Utilise sudo visudo ou indique un fichier précis :

sudo visudo -f /etc/sudoers.d/webteam

visudo verrouille le fichier de politique pendant la modification et vérifie sa syntaxe avant l’enregistrement. Une politique incorrecte peut empêcher les administrateurs d’utiliser sudo. Nomme le fichier webteam, et non webteam.conf : lors du traitement d’un répertoire inclus, sudo ignore les noms contenant un point ou se terminant par ~.

Les fichiers du répertoire inclus sont lus dans l’ordre de leurs noms. Lorsque plusieurs règles correspondent, la dernière détermine le résultat ; celle qui semble la plus précise ne l’emporte pas nécessairement. L’inclusion se trouve normalement vers la fin de la politique principale : un fichier supplémentaire peut donc modifier l’effet d’une règle écrite plus haut.

Autorise une action précise

Une équipe qui maintient un service web pourrait recevoir :

%webteam ALL=(root) /usr/bin/systemctl restart nginx

Un membre peut exécuter sudo systemctl restart nginx. La règle précise le chemin complet de la commande et ses arguments. Elle n’autorise ni systemctl stop nginx ni bash. Vérifie les droits effectifs avec sudo -l ; un administrateur peut examiner la politique de Bob avec sudo -l -U bob.

Le programme autorisé compte aussi. Un shell root peut tout faire. Les éditeurs et les pageurs peuvent démarrer des shells, et cp ou tee sans restriction peut écraser des fichiers de configuration protégés. Une liste de commandes apparemment courte peut donc donner un contrôle total.

Détermine si un mot de passe est nécessaire

NOPASSWD: supprime la demande d’authentification pour une commande correspondante :

backup ALL=(root) NOPASSWD: /usr/local/bin/backup.sh

Cela peut servir à une tâche automatisée. Le script doit être contrôlé par root : si backup peut le réécrire, ce compte peut remplacer son contenu par n’importe quelle commande exécutée en tant que root. Limite aussi l’action autorisée tout en protégeant le script.

Les lignes Defaults modifient les paramètres de la politique. Defaults timestamp_timeout=10 fixe un horodatage d’authentification de dix minutes ; Defaults logfile=/var/log/sudo.log sélectionne un fichier journal supplémentaire. Ces paramètres contrôlent le comportement de sudo, tandis que les règles de commande contrôlent les actions qu’il autorise.

La création d’un compte met en place une identité, un environnement de connexion et souvent un répertoire personnel. Choisir explicitement les options permet de prévoir le résultat sur les différentes distributions.

Crée un compte ordinaire

Supposons que le groupe developers existe déjà. Crée le compte de Priya et définis son mot de passe en deux commandes :

sudo useradd -m -s /bin/bash -c "Priya Shah" -G developers priya
sudo passwd priya

-m crée /home/priya et copie les fichiers initiaux de /etc/skel. -s /bin/bash choisit Bash comme shell de connexion et -c fournit le commentaire. -G developers ajoute une appartenance à un groupe supplémentaire ; plusieurs noms de groupes forment une liste séparée par des virgules sans espaces. Le compte reçoit normalement aussi un groupe principal privé.

La première commande ajoute des enregistrements de compte à /etc/passwd et /etc/shadow, ainsi que des enregistrements de groupe selon les besoins à /etc/group et /etc/gshadow. Son champ initial de mot de passe est verrouillé, souvent avec ! ou !!. Le compte existe avant de posséder un mot de passe utilisable. passwd priya définit ce mot de passe ; l’invite de saisie évite de l’inscrire dans la ligne de commande.

Comprends les valeurs par défaut des distributions

useradd est la commande de bas niveau utilisée pour créer des comptes sur les distributions Linux. Debian et Ubuntu fournissent aussi un script interactif adduser qui demande des informations et crée un répertoire personnel. Sur les systèmes de la famille Red Hat, adduser est un autre nom pour useradd et ne propose donc pas le même déroulement interactif.

Sans options explicites, useradd dépend des valeurs locales par défaut. Celles de la famille Red Hat créent couramment un répertoire personnel ; celles de Debian et Ubuntu ne le font pas sauf si -m est indiqué. Le shell par défaut peut aussi différer. Consulte useradd -D pour les valeurs par défaut comme le répertoire de base des répertoires personnels et le shell. /etc/default/useradd et /etc/login.defs fournissent des paramètres portant notamment sur les plages d’UID, les groupes privés et le vieillissement des mots de passe.

Indique un autre répertoire personnel ou une autre identité

Les options utiles décrivent des éléments distincts du compte :

Un chemin de répertoire personnel dans l’enregistrement ne crée pas le répertoire à lui seul. Associe -d à -m lorsque le nouveau répertoire personnel doit être créé. Sur Debian, omettre -m peut laisser un compte par ailleurs valide sans répertoire personnel utilisable à la connexion.

Pour une identité de service, sudo useradd -r -s /usr/sbin/nologin backupsvc demande un UID système et un shell non interactif. Les comptes système n’ont pas de répertoire personnel par défaut. Le shell nologin empêche une connexion ordinaire à un shell interactif sous cette identité.

Vérifie la configuration

Exécute getent passwd priya, id priya et ls -la /home/priya. Vérifie le chemin du répertoire personnel, le shell, le groupe principal, les groupes supplémentaires et les fichiers cachés copiés. /etc/skel est un modèle : y ajouter .bash_aliases affecte les répertoires personnels créés ensuite, pas ceux qui existent déjà. Utilise des noms de compte simples en minuscules, avec des chiffres, des traits d’union ou des tirets bas après la lettre initiale ; les espaces et les noms inhabituels sont rejetés ou mal gérés par de nombreux outils.

Un compte peut avoir besoin d’un nouveau mot de passe, d’un autre répertoire personnel, d’un blocage temporaire de l’accès ou d’une suppression définitive. Ces opérations modifient différentes parties du compte : détermine donc le résultat voulu avant de choisir une commande.

Modifie un mot de passe ou gère son vieillissement

Exécute passwd pour modifier ton propre mot de passe, normalement après avoir saisi le mot de passe actuel. Un administrateur utilise sudo passwd priya pour définir le mot de passe de Priya sans connaître l’ancien. Les contrôles de qualité peuvent rejeter les mots de passe courts ou simples.

sudo passwd -S priya indique l’état du mot de passe. sudo passwd -l priya verrouille le mot de passe en plaçant ! devant son empreinte, et sudo passwd -u priya le déverrouille. sudo passwd -e priya fait expirer le mot de passe afin que l’utilisateur doive en choisir un autre à sa prochaine connexion. Faire expirer un mot de passe est utile lorsqu’on en fournit un temporaire.

Utilise sudo chage -l priya pour examiner les dates de vieillissement. Par exemple :

sudo chage -M 90 -m 1 -W 7 priya

La durée maximale est de 90 jours, la durée minimale entre deux changements est d’un jour et les avertissements commencent sept jours avant l’expiration. Ces valeurs sont inscrites dans /etc/shadow. sudo chage -E 2026-12-31 priya définit la date d’expiration du compte entier, indépendamment de la durée de validité de son mot de passe.

Bloque l’accès sans supprimer les enregistrements

Le verrouillage d’un mot de passe bloque l’authentification par mot de passe. Il ne supprime pas les clés SSH et n’empêche pas toutes les autres méthodes d’authentification. Pour désactiver les connexions futures au compte d’un utilisateur qui part, verrouille le mot de passe et définis une date d’expiration du compte passée, par exemple avec sudo usermod -e 1 priya. La valeur 1 est un nombre de jours correspondant à janvier 1970 : cette date est donc déjà passée. Cela ne met pas fin aux processus déjà en cours d’exécution ; ils doivent être traités séparément.

Modifie un compte existant

usermod peut modifier le commentaire avec -c, le shell avec -s et le chemin du répertoire personnel avec -d. Associe -d et -m pour déplacer le contenu du répertoire personnel, comme dans sudo usermod -d /data/priya -m priya. -l newname modifie le nom de connexion, mais le répertoire personnel et le groupe privé conservent leurs noms existants sauf s’ils sont aussi modifiés. -L et -U verrouillent et déverrouillent le mot de passe.

Pour ajouter une appartenance à un groupe supplémentaire, exécute sudo usermod -aG developers priya. -a signifie ajouter à la liste. Sans cette option, usermod -G developers priya remplace toute la liste des groupes supplémentaires de Priya ; une appartenance antérieure à sudo peut disparaître. Son groupe principal est un paramètre distinct contrôlé par -g.

Supprime le compte et traite ses fichiers

sudo userdel priya supprime les enregistrements du compte mais conserve le répertoire personnel. sudo userdel -r priya supprime aussi le répertoire personnel et la boîte aux lettres locale. La commande normale refuse la suppression tant que l’utilisateur possède encore des processus en cours d’exécution.

Les fichiers situés ailleurs conservent l’UID numérique de leur propriétaire. Après la suppression du compte, un affichage peut indiquer 1003 comme propriétaire, car aucun nom ne lui correspond. Si cet UID est réutilisé pour un nouveau compte, ce compte devient propriétaire des anciens fichiers. Utilise sudo find / -nouser pour localiser les fichiers sans utilisateur correspondant, puis archive-les ou réattribue-les. Lors d’un départ, bloque d’abord les connexions futures, traite l’activité en cours et conserve les fichiers nécessaires, puis supprime le compte une fois ces tâches terminées.

Un dossier partagé a besoin d’un groupe, de membres et de droits sur le répertoire qui permettent à ces membres de travailler. Après un changement d’appartenance à un groupe, la base de données des comptes et les groupes d’un shell déjà en cours d’exécution peuvent temporairement différer.

Crée et gère le groupe

sudo groupadd developers attribue le prochain GID disponible. Ajoute -g 1500 pour choisir un GID précis ou -r pour créer un groupe système. Vérifie avec getent group developers ; un dernier champ vide signifie qu’aucun membre supplémentaire n’est encore listé.

Ajoute un membre avec l’une ou l’autre commande :

sudo usermod -aG developers priya
sudo gpasswd -a priya developers

sudo gpasswd -d priya developers supprime cette appartenance supplémentaire. sudo gpasswd -M alice,bob developers définit toute la liste des membres en remplaçant celle qui existait. Choisis l’ajout, le retrait ou le remplacement selon la modification voulue.

Actualise les groupes d’une session

Après l’ajout de Priya, id priya interroge la base de données des comptes et affiche immédiatement la nouvelle appartenance. Dans son shell existant, id seul indique les groupes que ce shell utilise effectivement. Ceux-ci ont été définis au début de la session.

Une nouvelle connexion charge la nouvelle liste. newgrp developers offre une autre solution : cette commande démarre un nouveau shell avec developers comme groupe principal. Utilise exit pour quitter ce shell. Lors du diagnostic d’une opération refusée, examine l’identité dans la session qui tente l’opération, et pas seulement l’entrée de la base de données.

Renomme ou supprime un groupe

sudo groupmod -n devteam developers modifie le nom mais conserve le GID. Les fichiers existants continuent de faire référence au même groupe numérique. En revanche, sudo groupmod -g 1600 developers modifie le numéro du groupe. Les fichiers qui portent encore l’ancien GID 1005 doivent être traités ; localise-les avec sudo find / -gid 1005, puis utilise chgrp pour leur attribuer le groupe voulu.

sudo groupdel developers refuse la suppression si un utilisateur existant a encore ce groupe comme groupe principal. Définis un autre groupe principal avec usermod -g avant de le supprimer. Supprimer un nom de groupe n’efface pas les fichiers qui portent son ancien GID.

Configure un dossier d’équipe

Pour l’équipe web de Priya et Kenji :

sudo groupadd webteam
sudo usermod -aG webteam priya
sudo usermod -aG webteam kenji
sudo mkdir /srv/web
sudo chgrp webteam /srv/web
sudo chmod 2770 /srv/web

Après s’être reconnectés, les deux utilisateurs peuvent créer des fichiers dans /srv/web. Le mode 2770 donne rwx au propriétaire et au groupe, --- aux autres, et active SGID sur le répertoire. Un nouveau fichier prend le groupe webteam, même lorsque le groupe principal de son créateur est son groupe privé. Les nouveaux sous-répertoires héritent aussi de SGID.

Le répertoire permet aux membres de l’équipe de travailler ensemble et empêche les autres d’y entrer, mais chaque fichier conserve son propre mode. Pour une demande habituelle de 666 sur un fichier, un masque de création de 002 donne au groupe le droit d’écriture, tandis que 022 ne lui laisse que la lecture. Si les membres de l’équipe doivent modifier les fichiers des autres, vérifie ces valeurs de création par défaut ainsi que le dossier.

Un affichage détaillé présente sur une ligne les informations nécessaires pour déterminer l’accès. Lis le propriétaire et le groupe avec les neuf bits de droits ; les bits seuls ne t’indiquent pas quels droits reçoit une personne donnée.

Déchiffre un affichage détaillé

-rw-r----- 1 priya developers 2048 Oct 22 09:15 report.txt

Le premier champ indique le type de fichier et ses droits. Les champs suivants donnent le nombre de liens physiques, l’utilisateur propriétaire, le groupe propriétaire, la taille en octets, la date de modification et le nom. Ce fichier ordinaire appartient à Priya et au groupe developers. Sa taille est de 2 048 octets ; la date affichée correspond à la dernière modification du contenu.

Le premier caractère est - pour un fichier ordinaire, d pour un répertoire ou l pour un lien symbolique. Tu peux aussi rencontrer c et b pour les périphériques en mode caractère et en mode bloc, p pour un tube nommé et s pour un socket.

Sépare les neuf positions suivantes en trois triplets :

Dans chaque triplet, les positions signifient lecture, écriture et exécution, dans cet ordre. Un tiret indique un droit absent, pas une position vide à ignorer lors du comptage.

Choisis exactement une catégorie

Pour une vérification ordinaire des droits, Linux procède ainsi :

1. L’utilisateur du processus correspond-il au propriétaire du fichier ? Utilise le triplet du propriétaire.
2. Sinon, l’un de ses groupes correspond-il au groupe du fichier ? Utilise le triplet du groupe.
3. Sinon, utilise le triplet des autres.

Les catégories ne s’additionnent pas. Supposons que Priya possède un fichier dont la chaîne complète du type et du mode est ----rw-rw-. Son triplet de propriétaire est --- : elle ne peut donc pas le lire au moyen des bits ordinaires, même si le groupe et les autres ont rw-. En tant que propriétaire, elle peut modifier le mode. Un triplet moins restrictif pour le groupe ou les autres ne remplace pas le triplet sélectionné du propriétaire.

Root peut contourner les vérifications ordinaires des droits de lecture et d’écriture. Pour exécuter un fichier programme ordinaire, même root a besoin d’au moins un bit d’exécution sur ce fichier. Vérifier un mode exige donc de connaître l’identité de l’utilisateur et l’opération tentée.

Examine les répertoires et les numéros

ls -ld /srv/web affiche le répertoire lui-même. Sans -d, ls -l /srv/web liste normalement les entrées qu’il contient, ce qui peut détourner ton attention d’une restriction sur le répertoire. ls -a inclut les noms cachés, tandis que ls -n affiche les propriétaires et les groupes sous forme numérique. Les fichiers stockent les UID et les GID ; si un compte ou un groupe a été supprimé, un affichage ordinaire peut aussi montrer le numéro restant.

Pour un compte rendu compact, exécute :

stat -c '%A %a %U %G %n' report.txt

La commande peut afficher -rw-r----- 640 priya developers report.txt, en plaçant les lettres et les chiffres octaux côte à côte. Un + après les lettres indique des entrées supplémentaires de liste de contrôle d’accès. Un lien symbolique affiche couramment lrwxrwxrwx ; Linux utilise les droits de la cible pour déterminer l’accès, pas les bits affichés pour le lien.

La lecture, l’écriture et l’exécution désignent des actions différentes sur les fichiers et les répertoires. Un répertoire stocke des noms qui donnent accès à des fichiers : modifier le contenu d’un fichier et supprimer son nom donnent donc lieu à des vérifications de droits différentes.

Associe le bit à l’objet

Un fichier doté du droit d’écriture mais pas de lecture peut recevoir du contenu en fin de fichier sans être lu. Par exemple, un shell peut ouvrir un journal accessible en écriture pour echo text >> log.txt même si cat log.txt échoue. Un éditeur a souvent besoin à la fois de lecture et d’écriture, car il charge d’abord le contenu existant.

Un script exécuté avec ./backup.sh a besoin du droit d’exécution et doit être lisible par son interpréteur. Si le script est lisible mais n’a pas le droit d’exécution, bash backup.sh peut encore le lire et l’exécuter : Bash est le programme exécutable dans cette commande.

Distingue l’affichage des noms du parcours

Le droit de lecture sur un répertoire permet de voir les noms. Le droit d’exécution sur un répertoire, aussi appelé droit de parcours, permet d’accéder à une entrée par son nom. Avec la lecture mais sans l’exécution, ls peut afficher les noms, tandis que ls -l ne peut pas obtenir leurs détails et peut afficher des erreurs et des points d’interrogation. Tu ne peux pas ouvrir les fichiers désignés à travers ce répertoire.

Avec l’exécution mais sans la lecture, l’inverse est possible : tu peux accéder à notes.txt si tu connais déjà son nom exact, mais tu ne peux pas lister le répertoire pour découvrir les noms. Le mode du fichier lui-même doit toutefois autoriser l’accès demandé.

Examine tout le chemin

Pour lire /home/priya/notes/public.txt, Kenji a besoin du droit d’exécution sur chaque répertoire du chemin et du droit de lecture sur le fichier. Si /home/priya a le mode 700, son triplet pour les autres est --- ; Kenji est bloqué à cet endroit même si public.txt a le mode 644. Ajouter davantage de droits de lecture au fichier ne peut pas corriger l’absence d’un bit de parcours sur un répertoire situé plus haut.

Utilise ls -ld /home/priya /home/priya/notes pour examiner les répertoires eux-mêmes. À chaque niveau, choisis la catégorie qui s’applique à Kenji et vérifie son bit d’exécution. La catégorie pertinente peut changer d’un répertoire à l’autre, car leurs propriétaires et leurs groupes peuvent différer.

Prévois les suppressions et les changements de nom

Supprimer un fichier retire une entrée de répertoire. Kenji a besoin des droits d’écriture et d’exécution sur le répertoire qui le contient, pas du droit d’écriture sur le fichier. Dans un répertoire ordinaire accessible en écriture sans sticky bit, il peut supprimer le fichier en lecture seule de Priya. Inversement, être propriétaire d’un fichier ne lui permet pas de le supprimer d’un répertoire où il n’a pas le droit d’écriture.

Retirer le droit d’écriture d’un fichier sert donc à protéger son contenu contre les modifications, mais ne protège pas son nom contre la suppression. Le sticky bit d’un répertoire ajoute une restriction liée à la propriété pour la suppression et le changement de nom dans les dossiers partagés accessibles en écriture. L’accès au fichier et l’accès à l’entrée de répertoire répondent à des questions distinctes.

Utilise chmod pour modifier les droits d’un fichier ou d’un répertoire dont tu es propriétaire. Root peut aussi les modifier. Un accès en écriture par l’intermédiaire d’un groupe permet de modifier le contenu d’un fichier, mais ne fait pas de toi son propriétaire et ne te permet pas de définir son mode.

Effectue une modification symbolique ciblée

Un mode symbolique comporte une catégorie, un opérateur et des bits. Les catégories sont u pour le propriétaire, g pour le groupe, o pour les autres et a pour les trois. + ajoute des droits, - les retire et = définit exactement ceux de la catégorie.

chmod u+x deploy.sh
chmod go-w notes.txt
chmod u=rw,g=r,o= report.txt

La première commande ajoute uniquement le bit d’exécution du propriétaire. La deuxième retire l’écriture au groupe et aux autres tout en conservant leurs autres bits. La troisième donne au propriétaire la lecture et l’écriture, au groupe la lecture et aux autres aucun droit : rw-r-----.

Précise la catégorie lorsque tu veux une modification précise. Si tu l’omets, comme dans chmod +w notes.txt, le masque de création limite les bits des catégories qui sont modifiés. Avec le masque 022, cette commande ajoute l’écriture au propriétaire seulement ; chmod a+w notes.txt inclut explicitement les trois catégories.

Convertis chaque triplet en chiffre octal

La lecture vaut 4, l’écriture 2 et l’exécution 1. Additionne les valeurs présentes dans chaque catégorie :

Pour rw-r-----, sépare en rw-, r--, --- : les chiffres sont 6, 4, 0. chmod 640 report.txt définit ces neuf bits ordinaires, quel que soit le mode ordinaire précédent. Inverse le processus pour 750 : 7 donne rwx, 5 donne r-x et 0 donne ---, ce qui forme rwxr-x---.

Choisis un mode final adapté

Le mode 600 réserve un fichier à son propriétaire. Le mode 644 permet aux autres utilisateurs de lire un fichier ordinaire. Le mode 664 permet aussi au groupe de le modifier. Les répertoires privés utilisent couramment 700, les répertoires lisibles par le groupe 750 et ceux modifiables par le groupe 770. Les programmes ou les répertoires publics utilisent couramment 755.

Les mêmes chiffres permettent des actions différentes selon les objets. Appliquer 644 à un répertoire retire l’exécution à toutes les catégories. Même son propriétaire ne peut plus y entrer ni ouvrir les fichiers à travers ce répertoire. Utilise un mode de répertoire qui donne le droit de parcours aux personnes qui doivent accéder à ses entrées.

Applique les modifications à une arborescence

chmod -R 755 site/ rend aussi tous les fichiers ordinaires exécutables. Pour une arborescence contenant des répertoires et des documents ordinaires, utilise l’exécution conditionnelle :

chmod -R u=rwX,go=rX site/

Le X majuscule ajoute l’exécution aux répertoires et aux fichiers qui possèdent déjà un bit d’exécution. Les fichiers non exécutables passent à 644 ; les répertoires passent à 755. Les fichiers déjà exécutables conservent le droit d’exécution. Le parcours reste ainsi possible sans que chaque document soit marqué comme programme. Les bits spéciaux sont distincts : GNU chmod conserve SUID et SGID sur les répertoires sauf si tu les désactives explicitement, par exemple avec chmod g-s site/.

Le propriétaire et le groupe identifient l’utilisateur et le groupe dont les triplets de droits seront vérifiés. Les définir correctement peut réparer un dossier de travail créé par erreur avec sudo, sans donner un accès plus large à tous les autres.

Lis les formes de chown

chown peut modifier un utilisateur, un groupe ou les deux :

Les identifiants numériques fonctionnent aussi, comme dans sudo chown 1002:1005 report.txt. Les noms sont résolus en numéros ; le fichier stocke ces numéros.

Seul root peut transférer un fichier à un autre utilisateur propriétaire. Un propriétaire peut attribuer à son propre fichier un groupe auquel il appartient. Ainsi, Priya peut utiliser chgrp webteam plan.txt si elle possède le fichier et appartient à webteam. Elle devrait aussi appartenir à finance pour attribuer le fichier à ce groupe. Le fait qu’un autre membre puisse modifier le fichier ne lui donne pas la possibilité d’en changer le propriétaire ou le mode.

Répare un dossier appartenant à root par erreur

Kenji a exécuté une commande de création avec sudo. L’affichage est le suivant :

drwxr-xr-x 2 root root 4096 Oct 22 10:02 /home/kenji/app

Il n’est pas le propriétaire et n’utilise pas le groupe propriétaire : il reçoit donc les droits r-x des autres. Il peut examiner le dossier et y entrer, mais ne peut pas créer d’entrées car le droit d’écriture manque. Rendre le dossier accessible en écriture à tout le monde donnerait plus d’accès que son projet n’en nécessite.

Si le projet appartient à Kenji, sudo chown -R kenji: ~/app rétablit sa propriété et son groupe de connexion sur l’ensemble du dossier. Son triplet de propriétaire est maintenant rwx : il peut donc créer des fichiers. Examine le chemin cible avant toute commande récursive de modification du propriétaire ou du groupe : l’appliquer à /etc ou /usr peut empêcher le système de fonctionner. -R désigne le répertoire et tout ce qu’il contient.

Prévois le propriétaire et le groupe après des opérations sur les fichiers

Un fichier nouvellement créé appartient à l’utilisateur du processus qui le crée. Son groupe provient normalement du groupe principal de ce processus ou d’un répertoire parent SGID. Créer une nouvelle copie ordinaire avec cp rend donc l’utilisateur qui lance la commande propriétaire de cette copie. Un mv au sein du même système de fichiers change l’emplacement d’un fichier existant et conserve son propriétaire et son groupe. Les options de copie qui conservent le propriétaire et le groupe ont un comportement distinct de celui d’une nouvelle copie ordinaire.

Cette distinction explique pourquoi déplacer un ancien fichier dans un dossier partagé ne lui applique pas la règle d’héritage du groupe de ce dossier. SGID s’applique à la création ; utilise chgrp lorsque le groupe d’un fichier existant doit être modifié.

Associe l’identité à l’accès

Attribuer webteam avec chgrp détermine qui représente la catégorie groupe. Cela n’ajoute pas les droits de lecture ou d’écriture du groupe. Utilise chmod pour accorder les bits nécessaires après avoir choisi le groupe. Modifier le propriétaire ou le groupe d’un exécutable peut aussi effacer les privilèges SUID ou SGID ; examine son mode après la modification lorsque ces bits comptent.

Les droits d’un nouveau fichier proviennent de deux éléments : le mode demandé par le programme qui le crée et le masque de création du processus. Le masque retire des bits demandés ; il n’ajoute jamais de droits que le programme n’a pas demandés.

Pars du mode demandé à la création

Les éditeurs et la redirection du shell demandent généralement 666, soit rw-rw-rw-, pour les nouveaux fichiers ordinaires. La création d’un répertoire demande généralement 777, soit rwxrwxrwx. Un masque de création est un ensemble de bits à retirer à cette demande. Un bit n’est conservé que si la demande l’inclut et si le masque ne l’inclut pas.

Pour le masque 022, conserve tous les bits demandés pour le propriétaire, retire l’écriture au groupe et retire l’écriture aux autres. Un fichier obtient 644 ; un répertoire obtient 755. Lis chaque chiffre comme des bits, pas comme une quantité décimale ordinaire.

Avec 027, le groupe perd l’écriture tandis que les autres perdent les trois bits. Ce masque est utile lorsqu’une équipe doit pouvoir lire les nouveaux fichiers mais que les utilisateurs extérieurs à l’équipe ne doivent avoir aucun accès. Avec 002, l’écriture reste disponible pour le groupe ; le groupe propriétaire du fichier détermine toujours qui en bénéficie.

Pourquoi la soustraction ne fonctionne pas

Prends une demande de 666 pour un fichier et le masque 033. Chaque 3 signifie écriture et exécution. Mais chaque triplet demandé pour le fichier est rw- : l’exécution est déjà absente. Retirer l’écriture et l’exécution laisse r-- pour le groupe et les autres, le résultat est donc 644. Soustraire les chiffres donnerait 633, ce qui suggère à tort que des bits d’exécution peuvent apparaître.

Pour une demande de 777 sur un répertoire, retirer ces mêmes bits donne 744. Ce répertoire n’a pas le droit d’exécution pour le groupe et les autres : ces catégories ne peuvent donc pas accéder à ses entrées même si elles peuvent lister les noms. Un masque qui donne le mode de fichier souhaité peut produire un résultat peu pratique pour les répertoires.

Examine et définis ton masque

Exécute umask pour voir la valeur actuelle, souvent affichée avec un zéro initial, comme 0022. Ce zéro relève du formatage ; Linux utilise les neuf bits de droits ordinaires. umask -S affiche les bits autorisés, comme u=rwx,g=rx,o=rx pour 022 ; un programme peut demander une partie seulement de ces bits.

umask 027 modifie le masque du shell courant, dont héritent les programmes qu’il démarre. Les fichiers existants conservent leur mode. Utilise chmod lorsqu’un fichier déjà créé a besoin de droits différents.

Choisis une valeur par défaut persistante

Une ligne comme umask 027 dans ~/.profile ou ~/.bashrc peut définir la valeur pour les shells qui lisent ce fichier de démarrage. Les valeurs par défaut du système peuvent provenir de /etc/profile ou de UMASK dans /etc/login.defs. La distribution et la configuration du compte déterminent quels fichiers sont lus et à quel moment.

Beaucoup de systèmes utilisent 022, tandis que les configurations avec groupes privés utilisent souvent 002 pour les utilisateurs ordinaires. Un compilateur peut demander une sortie exécutable avec le mode 777 ; avec 022, elle obtient 755. La demande de 666 d’un éditeur de texte ne contient aucun bit d’exécution : écrire un script ne le rend donc pas exécutable en soi.

Trois bits spéciaux ajoutent des comportements aux droits ordinaires du propriétaire, du groupe et des autres. Leur signification dépend du fait que l’objet est un programme ou un répertoire.

Reconnais le chiffre supplémentaire

Un chiffre octal initial combine SUID 4, SGID 2 et sticky 1. Le mode 4755 correspond à SUID avec le mode ordinaire 755. Le mode 2770 correspond à SGID avec 770. Le mode 3770 combine SGID et sticky, car 2 plus 1 font 3.

Dans un affichage détaillé, les bits occupent les positions d’exécution. Un s minuscule à la position du propriétaire signifie SUID et exécution pour le propriétaire ; un s minuscule à la position du groupe signifie SGID et exécution pour le groupe. Un t minuscule à la position des autres signifie sticky et exécution pour les autres. Un S ou un T majuscule signifie que le bit spécial est présent mais que l’exécution est absente à cette position.

SUID et SGID sur les programmes

SUID permet à un exécutable de fonctionner avec l’identité effective du propriétaire de son fichier. /usr/bin/passwd apparaît couramment sous la forme -rwsr-xr-x root root : le programme peut mettre à jour les données protégées des mots de passe tout en contrôlant le mot de passe que l’utilisateur qui le lance est autorisé à modifier. Son lancement ne donne pas à cet utilisateur un shell root. Linux ignore SUID sur les scripts et les répertoires.

SGID sur un exécutable utilise de la même façon l’identité du groupe du fichier. Ces bits donnent un accès contrôlé par le programme : son comportement compte donc. N’ajoute jamais SUID à un shell, un éditeur ou un script. Un administrateur peut inventorier les fichiers ordinaires SUID avec sudo find / -perm -4000 -type f 2>/dev/null ; utilise -perm -2000 pour les fichiers SGID et compare les résultats avec la configuration attendue du système.

SGID sur un répertoire d’équipe

Sur un répertoire, SGID fait prendre aux nouvelles entrées le groupe du répertoire, et les nouveaux sous-répertoires héritent de SGID. Supposons que /srv/web appartienne à root:webteam, avec le mode 2770, affiché sous la forme drwxrws---. Priya possède un groupe principal privé mais appartient à webteam. Lorsqu’elle crée index.html dans ce répertoire, son groupe devient webteam.

Son mode ordinaire dépend toujours de sa création. Avec une demande de 666 pour le fichier et un masque de création de 002, il obtient 664 et Kenji, un autre membre de l’équipe, peut le modifier. Avec 022, il obtient 644 : Kenji n’a donc que le droit de lecture. SGID fournit le groupe, pas un bit d’écriture supplémentaire.

Répertoires avec sticky bit et suppression

Le sticky bit restreint la suppression et le changement de nom : avec les droits nécessaires sur le répertoire, une entrée peut être supprimée par le propriétaire de son fichier, le propriétaire du répertoire ou root. Les répertoires partagés accessibles en écriture restent ainsi utiles sans permettre aux utilisateurs de supprimer les entrées des autres. /tmp et /var/tmp utilisent couramment 1777, affiché sous la forme drwxrwxrwt. Le sticky bit n’empêche pas de modifier le contenu d’un fichier lorsque son mode le permet. Linux l’ignore sur les fichiers ordinaires.

Active les bits avec chmod u+s prog, chmod g+s /srv/web ou chmod o+t /srv/drop. Désactive-les avec u-s, g-s ou o-t. Avec GNU chmod, chmod 755 /srv/web conserve un bit SGID existant sur le répertoire ; utilise chmod g-s /srv/web pour le désactiver explicitement.

Une erreur « Permission denied » indique qu’une opération a échoué, mais pas nécessairement que le mode d’un fichier est incorrect. Le blocage peut venir des groupes de ta session, d’un répertoire parent, du fichier lui-même ou du propriétaire attribué par une commande aux droits élevés.

Examine l’identité, le chemin, la catégorie et l’opération

Commence par exécuter id seul dans la session concernée. Si un groupe a été ajouté récemment, compare la liste active avec id username, qui interroge la base de données. Une nouvelle connexion peut charger la nouvelle appartenance.

Examine ensuite tout le chemin :

namei -l /srv/reports/q3.txt

namei -l indique les propriétaires, les groupes et les modes tout au long du chemin. Tu peux aussi examiner chaque répertoire avec ls -ld. Pour chaque objet, sélectionne la première catégorie correspondante : propriétaire, sinon groupe, sinon autres. Demande-toi ensuite de quels droits l’opération tentée a besoin. La lecture nécessite r sur le fichier et le droit de parcours sur tous les répertoires parents. La création, la suppression ou le changement de nom d’une entrée nécessite w et x sur son répertoire, avec les restrictions du sticky bit lorsqu’il est présent.

Trouve la première opération bloquée

Kenji appartient à finance et tente cat /srv/reports/q3.txt. Les objets concernés sont :

drwxr-xr-x root  root     /srv
drwxr-x--- root  finance  /srv/reports
-rw------- maria finance  /srv/reports/q3.txt

Kenji peut traverser /srv grâce au droit d’exécution des autres. Dans /srv/reports, son appartenance à finance sélectionne le r-x du groupe : il peut donc aussi le traverser. Sur q3.txt, il n’est pas Maria et le triplet de finance est ---. Le droit manquant est la lecture du fichier pour le groupe.

Si les membres de finance doivent pouvoir lire le rapport, Maria ou root peut exécuter chmod g+r /srv/reports/q3.txt. Le mode obtenu est 640. Il fournit le droit manquant sans donner l’écriture au groupe ni ouvrir le rapport aux autres. Un administrateur peut tester avec sudo -u kenji cat /srv/reports/q3.txt, en exécutant la commande sous l’identité de Kenji plutôt qu’en la testant en tant que root.

Choisis la correction la plus limitée

Une correction adaptée peut consister à ajouter une personne au groupe de l’équipe, à définir la lecture pour le groupe, à rétablir le propriétaire d’un projet ou à ajouter le droit de parcours du répertoire pour la catégorie voulue. chmod -R 777 donne à tous les comptes locaux un accès en écriture dans toute l’arborescence et rend les fichiers ordinaires exécutables. Cette commande ne peut pas non plus résoudre toutes les causes d’un échec d’accès.

Vérifie les causes courantes avant de modifier une grande arborescence : une nouvelle appartenance inactive, un x manquant sur un répertoire parent, des fichiers de travail créés avec sudo et appartenant à root, et de nouveaux fichiers dont le masque de création a retiré l’accès nécessaire à l’équipe. Les lecteurs FAT32 et exFAT ne stockent pas les UID, GID et modes natifs de Linux ; les options de montage fournissent ces valeurs, si bien que chmod ou chown appliqué à un fichier peut échouer ou rester sans effet.

Protège les données privées

Une clé privée SSH comme ~/.ssh/id_ed25519 doit normalement avoir le mode 600 ; son répertoire .ssh a généralement le mode 700. SSH vérifie la protection de la clé privée et peut rejeter une clé trop accessible. /etc/shadow reste inaccessible aux utilisateurs ordinaires. Les administrateurs disposant de tous les droits sudo peuvent contourner les protections ordinaires des fichiers privés : limite donc leur nombre et autorise des actions précises lorsque tous les droits d’administration ne sont pas nécessaires.