Corriger les permissions en masse : prendre la propriété sans casser l’héritage

Savoir ce que « héritage » signifie réellement sur Linux

On parle d’« héritage » comme s’il s’agissait d’une propriété universelle des permissions. Ce n’est pas le cas. Sur Linux, l’héritage est un comportement émergent créé par plusieurs mécanismes distincts :

1) Les bits de mode POSIX (chmod) n’héritent pas

Les répertoires ont des permissions ; les fichiers ont des permissions. La création d’un nouveau fichier dans un répertoire ne « hérite » pas des bits de mode du répertoire parent. Le nouveau fichier obtient un mode basé sur le processus créateur et son umask, pas sur le rwx du répertoire parent.

2) Le bit setgid sur les répertoires est une forme d’héritage de groupe

Si un répertoire a le bit setgid (chmod g+s), les fichiers et répertoires nouvellement créés héritent typiquement de la propriété de groupe du répertoire. C’est l’outil ancien mais étonnamment efficace pour les dossiers d’équipe partagée.

3) Les ACL POSIX fournissent un vrai héritage via les « ACL par défaut »

Les ACL vous donnent des utilisateurs/groupes nommés, des masques et des valeurs par défaut. Un répertoire peut avoir des entrées ACL par défaut qui sont appliquées aux nouveaux objets créés à l’intérieur. C’est la chose la plus proche de l’héritage à la Windows que vous obtenez en ACL POSIX natives.

4) « Prendre la propriété » est une décision de politique, pas juste une commande

Quand vous exécutez chown, vous changez qui peut modifier les permissions, qui peut changer les ACL, et qui est effectivement responsable. Bien fait, cela restaure l’ordre. Mal fait, c’est un coup silencieux.

5) Le masque ACL est le tueur silencieux

Sur les systèmes utilisant des ACL POSIX, l’entrée mask peut restreindre les permissions effectives pour les utilisateurs et groupes nommés. Ainsi vous pouvez « accorder » l’accès et voir quand même Permission denied parce que le masque l’empêche. C’est comme ça que des ingénieurs rationnels perdent un après-midi.

Une idée paraphrasée d’une sommité de la fiabilité convient ici : idée paraphrasée — « Tout échoue ; concevez pour que les échecs soient prévisibles et récupérables. » — Richard Cook (idée paraphrasée)

Faits intéressants et historique à utiliser dans les arguments

• Fait 1 : Les permissions Unix traditionnelles (owner/group/other) remontent aux débuts d’Unix dans les années 1970, optimisées pour la simplicité plutôt que l’expressivité.
• Fait 2 : Les bits setuid/setgid/sticky n’étaient pas tant des « fonctionnalités de sécurité » que des astuces pragmatiques pour des systèmes multi-utilisateurs nécessitant des flux de travail partagés.
• Fait 3 : Les ACL POSIX sont devenues courantes sur Linux au début des années 2000, lorsque les entreprises ont exigé un contrôle d’accès plus fin que les bits de mode pouvaient fournir.
• Fait 4 : L’entrée ACL mask existe pour fournir un plafond sur les permissions effectives—utile pour le contrôle, catastrophique pour l’intuition.
• Fait 5 : Sur de nombreux systèmes de fichiers Linux, le support des ACL est intégré, mais vous avez toujours besoin des outils userland (getfacl, setfacl) pour les gérer proprement.
• Fait 6 : SMB/CIFS (Samba) mappe souvent la sémantique des ACL Windows sur des ACL POSIX ou des attributs étendus, ce qui peut sembler « juste » sous Windows et « bizarre » sous Linux.
• Fait 7 : NFS a eu plusieurs modèles de sécurité selon les versions ; ce qui « fonctionne » sur NFSv3 avec mappage d’UID peut se casser spectaculairement lorsqu’on modifie la gestion des identités.
• Fait 8 : rsync peut préserver la propriété, les bits de mode, les xattrs et les ACL—mais seulement si vous le lui demandez explicitement et si la cible les supporte.
• Fait 9 : Le sticky bit sur les répertoires (comme /tmp) est un mécanisme simple mais puissant pour la sécurité multi-utilisateurs : vous pouvez créer des fichiers, mais pas supprimer ceux des autres.

Mode d’emploi pour diagnostic rapide (trouver le goulot vite)

Voici la séquence « arrêter de deviner ». Exécutez-la dans l’ordre. Elle réduit rapidement le problème à l’identité, au système de fichiers, à la sémantique des ACL ou aux outils.

Première étape : identifier le chemin d’accès et la traduction d’identité

1. D’où provient l’accès ? shell local, SSH, Samba, NFS, montage bind dans un conteneur ?
2. Qui est l’utilisateur ? l’UID/GID numérique compte plus que les noms dans de nombreux modes d’échec.
3. Y a-t-il un décalage d’identité ? changements AD/LDAP/SSSD, idmap, problèmes d’idmapping NFS.

Deuxième étape : vérifier les permissions effectives au point d’échec

1. Le bit exécution (x) sur chaque segment de chemin parent.
2. Les entrées ACL POSIX et le masque ACL.
3. Les options de montage (par ex. noacl, nosuid, root squashing en NFS).

Troisième étape : décider si vous réparez la propriété, les ACL, ou les deux

1. Si la propriété est erronée mais que les ACL sont correctes, privilégiez le chown ciblé.
2. Si les ACL par défaut manquent, corrigez les ACL par défaut du répertoire, pas chaque fichier.
3. Si le modèle est incohérent, capturez/sauvegardez les métadonnées et reconstruisez à partir d’une politique connue.

Blague 1 : Si votre modèle de permissions nécessite une présentation de 40 diapositives, ce n’est pas un modèle. C’est une prise d’otages.

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont les tâches que j’exécute réellement pendant des incidents et des migrations. Chacune inclut ce que signifie la sortie et quelle décision en découle.

Tâche 1 : Confirmer le type de système de fichiers et les options de montage (les ACL peuvent être désactivées)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /srv/share
/dev/sdb1 /srv/share ext4 rw,relatime,errors=remount-ro

Signification : Vous êtes sur ext4 avec des options normales. Si vous voyez noacl (ou un montage NFS sans les fonctionnalités attendues), attendez-vous à un comportement ACL différent.

Décision : Si les options de montage sont en conflit avec votre stratégie de permissions, corrigez la config de montage avant de toucher aux permissions. Sinon vous « corrigerez » des métadonnées que le noyau ignore.

Tâche 2 : Reproduire en tant qu’utilisateur affecté et capturer l’échec exact

cr0x@server:~$ sudo -u alice bash -lc 'cd /srv/share/team && touch testfile'
touch: cannot touch 'testfile': Permission denied

Signification : Il s’agit d’un échec d’écriture/création, pas de lecture. Sur les répertoires, la création requiert w et x sur le répertoire.

Décision : Concentrez-vous sur les permissions/ACL du répertoire, pas sur les permissions des fichiers. Vous pouvez faire des chmod sur des fichiers indéfiniment ; la création échouera toujours si le répertoire n’est pas correct.

Tâche 3 : Vérifier l’identité numérique et l’appartenance aux groupes (les noms peuvent mentir)

cr0x@server:~$ id alice
uid=10501(alice) gid=10501(alice) groups=10501(alice),12000(finance),12010(shared-team)

Signification : Alice est dans shared-team. Si elle ne l’était pas, votre « problème de permissions » pourrait être un problème d’approvisionnement d’identité/groupe.

Décision : Si l’appartenance au groupe manque, corrigez IAM/LDAP/AD/SSSD d’abord. Ne maquillez pas un problème d’identité avec des ACL permissives.

Tâche 4 : Inspecter les bits de mode du répertoire (avons-nous le bit exécution ?)

cr0x@server:~$ namei -l /srv/share/team
f: /srv/share/team
drwxr-xr-x root root /
drwxr-xr-x root root srv
drwxr-x--- root shared-team share
drwxrwx--- root shared-team team

Signification : Le chemin semble traversable pour le groupe sur /srv/share et /srv/share/team. Si un parent manquait de x pour la classe pertinente, la traversée échouerait.

Décision : Si la traversée échoue, corrigez d’abord le répertoire parent. Une ACL parfaite sur la feuille ne servira à rien si vous ne pouvez pas l’atteindre.

Tâche 5 : Vérifier les ACL et le masque sur le répertoire

cr0x@server:~$ getfacl -p /srv/share/team
# file: /srv/share/team
# owner: root
# group: shared-team
user::rwx
group::rwx
other::---
mask::r-x
default:user::rwx
default:group::rwx
default:other::---

Signification : Le mask::r-x plafonne les permissions de groupe à lecture/exécution alors que group::rwx existe. Cela peut bloquer les écritures.

Décision : Corrigez le masque (setfacl -m m::rwx) ou réappliquez les entrées ACL avec une gestion correcte du masque. N’ajoutez pas aveuglément des utilisateurs ; vous serez toujours bloqué.

Tâche 6 : Afficher les permissions effectives des ACL (éviter l’auto-tromperie)

cr0x@server:~$ getfacl -p /srv/share/team | sed -n '1,20p'
# file: /srv/share/team
# owner: root
# group: shared-team
user::rwx
group::rwx              #effective:r-x
other::---
mask::r-x
default:user::rwx

Signification : L’annotation #effective vous dit la vérité : le groupe est effectivement r-x, pas rwx.

Décision : Si les permissions effectives ne correspondent pas à l’intention, traitez le masque comme un réglage de configuration à part entière, pas comme une pensée secondaire.

Tâche 7 : Corriger seulement le masque ACL du répertoire (changement chirurgical)

cr0x@server:~$ setfacl -m m::rwx /srv/share/team
cr0x@server:~$ getfacl -p /srv/share/team | grep -E 'mask|group::'
group::rwx
mask::rwx

Signification : Le masque permet maintenant les écritures. Si les utilisateurs ne peuvent toujours pas créer de fichiers, le suspect suivant est les ACL par défaut et le umask.

Décision : Retestez la création en tant qu’utilisateur. Si c’est corrigé, arrêtez. Ne continuez pas à « améliorer » les permissions après la résolution de l’incident.

Tâche 8 : Vérifier les ACL par défaut (héritage pour les nouveaux fichiers)

cr0x@server:~$ getfacl -p /srv/share/team | grep -E '^default:'
default:user::rwx
default:group::rwx
default:other::---

Signification : Une ACL par défaut existe, mais elle peut manquer d’entrées nommées pour les groupes requis, ou le masque par défaut peut être incorrect.

Décision : Si vous avez besoin que plusieurs groupes héritent des accès, ajoutez des entrées de groupe nommées par défaut et définissez un masque par défaut approprié.

Tâche 9 : Ajouter une ACL par défaut pour un groupe collaboratif (et la garder héritée)

cr0x@server:~$ setfacl -m d:g:finance:rwx /srv/share/team
cr0x@server:~$ setfacl -m d:m::rwx /srv/share/team
cr0x@server:~$ getfacl -p /srv/share/team | grep -E 'default:group:finance|default:mask'
default:group:finance:rwx
default:mask::rwx

Signification : Les nouveaux fichiers/répertoires créés sous /srv/share/team hériteront d’une entrée ACL pour le groupe finance, soumise au masque par défaut.

Décision : Si l’héritage est l’objectif, configurez toujours des defaults sur les répertoires. N’appliquez pas récursivement des ACL sur les fichiers existants sauf si nécessaire.

Tâche 10 : Confirmer le setgid sur le répertoire (continuité de la propriété de groupe)

cr0x@server:~$ stat -c '%A %U %G %n' /srv/share/team
drwxrwx--- root shared-team /srv/share/team

Signification : Aucun bit setgid affiché (s apparaîtrait dans la position d’exécution du groupe). Sans lui, les nouveaux fichiers peuvent prendre le groupe primaire du créateur, pas shared-team.

Décision : Pour les répertoires de collaboration, activez setgid sauf si vous avez une bonne raison de ne pas le faire.

Tâche 11 : Activer setgid et valider le comportement avec un fichier de test

cr0x@server:~$ chmod g+s /srv/share/team
cr0x@server:~$ stat -c '%A %U %G %n' /srv/share/team
drwxrws--- root shared-team /srv/share/team
cr0x@server:~$ sudo -u alice bash -lc 'touch /srv/share/team/owned-by-group && stat -c "%U %G %n" /srv/share/team/owned-by-group'
alice shared-team /srv/share/team/owned-by-group

Signification : La propriété de groupe reste maintenant cohérente. Cela réduit les tickets futurs « pourquoi ce fichier appartient-il au mauvais groupe ? »

Décision : Maintenez setgid sur les répertoires à forte collaboration. C’est ennuyeux. L’ennui, c’est bien.

Tâche 12 : Prévisualiser le rayon d’impact avant un changement récursif de propriété

cr0x@server:~$ find /srv/share/team -maxdepth 2 -printf '%u:%g %m %p\n' | head
root:shared-team 2770 /srv/share/team
root:shared-team 2770 /srv/share/team/projects
bob:shared-team 0660 /srv/share/team/projects/notes.txt
carol:finance 0660 /srv/share/team/projects/budget.xlsx

Signification : Vous avez des propriétaires et groupes mixtes. Un chown -R root:shared-team à l’aveugle écraserait des schémas de propriété par projet délibérés.

Décision : Si une propriété mixte est attendue, évitez le chown global. Si c’est accidentel, définissez des règles (ce qui doit changer, ce qui doit rester).

Tâche 13 : Changer la propriété en toute sécurité avec des filtres (cibler seulement ce qui est erroné)

cr0x@server:~$ find /srv/share/team -group finance -print | head -n 3
/srv/share/team/projects/budget.xlsx
/srv/share/team/projects/q1
/srv/share/team/archive/old

Signification : Ces objets ont le groupe finance. Peut-être que c’est incorrect. Peut-être que c’est correct. Maintenant vous savez où ils sont.

Décision : Utilisez des prédicats find pour restreindre les changements. Votre futur vous remerciera pour cette retenue.

Tâche 14 : Effectuer un chgrp ciblé (seulement le groupe) et vérifier un échantillon

cr0x@server:~$ sudo chgrp shared-team /srv/share/team/projects/budget.xlsx
cr0x@server:~$ stat -c '%U %G %n' /srv/share/team/projects/budget.xlsx
carol shared-team /srv/share/team/projects/budget.xlsx

Signification : Groupe ajusté, propriétaire préservé. C’est généralement moins risqué que de changer les deux.

Décision : Préférez chgrp à chown quand la propriété n’est pas le problème.

Tâche 15 : Sauvegarder les ACL et les xattrs avant des modifications massives (votre plan de retour arrière)

cr0x@server:~$ getfacl -R -p /srv/share/team > /root/team.acl.backup
cr0x@server:~$ wc -l /root/team.acl.backup
48231 /root/team.acl.backup

Signification : Vous avez une sauvegarde texte des métadonnées ACL. Pas parfaite, mais c’est un vrai levier de restauration.

Décision : Si vous ne pouvez pas faire de snapshot, capturez au moins les métadonnées. Des changements massifs sans possibilité de retour arrière, c’est jouer au casino avec des données de production.

Tâche 16 : Restaurer les ACL depuis la sauvegarde si vous vous êtes planté

cr0x@server:~$ setfacl --restore=/root/team.acl.backup
cr0x@server:~$ echo $?
0

Signification : Le code de sortie 0 indique que la restauration a réussi. Vous devez quand même effectuer des vérifications ponctuelles.

Décision : Lors de la restauration, validez quelques répertoires et fichiers critiques. Faites confiance, mais vérifiez—surtout après avoir prouvé que vous pouvez vous tromper.

Stratégie d’ownership en masse sans dommages collatéraux

« Prendre la propriété » est généralement un raccourci pour l’un des trois objectifs :

• Contrôle opérationnel : un compte de service ou un groupe d’admins doit pouvoir réparer les permissions plus tard.
• Correction d’accès : les utilisateurs finaux doivent pouvoir lire/écrire à nouveau.
• Application de politique : tout dans un arbre doit respecter une norme connue.

Ces objectifs nécessitent des tactiques différentes. Traitez-les différemment, sinon vous réparerez l’incident et casserez votre modèle de gouvernance. Oui, les deux sont mauvais ; l’un se verra dans les audits plutôt que dans les pages d’alerte.

Quand il ne faut pas exécuter chown -R

Un changement récursif de propriété est approprié lorsque les propriétaires actuels sont clairement erronés (par ex., tout est possédé par un UID de migration retiré, ou par root parce qu’une restauration a été faite en root). Ce n’est pas approprié quand :

• L’arbre contient plusieurs projets avec des propriétaires différents par conception.
• Des applications comptent sur des propriétaires spécifiques pour des frontières de sécurité.
• Les ACL encodent déjà la politique d’accès et la propriété sert seulement à savoir « qui peut chmod ».

Prendre la propriété tout en préservant l’héritage : le schéma sûr

Voici le schéma qui fonctionne sur la plupart des configurations de fichiers partagés :

1. Corriger d’abord l’héritage au niveau des répertoires : setgid + ACL par défaut + masques corrects.
2. Arrêter d’utiliser la propriété comme contrôle d’accès dans les arbres partagés. Utilisez la politique de groupe + ACL pour l’accès, réservez la propriété pour le contrôle administratif.
3. Normaliser uniquement ce qui doit l’être : répertoires et zones de fichiers critiques pour la collaboration, pas les archives historiques sauf si nécessaire.
4. Valider avec des actions réelles d’utilisateurs : créer, renommer, supprimer, éditer. La lecture est la partie facile.

Ce que « ne pas casser l’héritage » signifie réellement

Cela signifie que vous ne supprimez pas accidentellement :

• les entrées ACL par défaut sur les répertoires,
• le setgid sur les répertoires de collaboration,
• les valeurs de masque ACL prévues,
• les attentes de mappage Samba/NFS (IDs, xattrs),
• les besoins en permissions spécifiques aux applications.

Blague 2 : chmod 777 c’est comme débrancher l’alarme incendie parce qu’elle est bruyante. Calme, oui. Mieux, non.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils avaient un serveur de fichiers Linux exportant un partage via Samba. Un nouvel ingénieur—intelligent, rapide, dangereusement optimiste—a supposé que l’héritage façon Windows était « stocké dans le dossier » et se propagerait naturellement.

Pendant une réorganisation, ils ont créé un nouveau répertoire de niveau supérieur, copié les données à l’intérieur, et ajusté les permissions au sommet en utilisant un client Windows. Les permissions semblaient correctes dans l’Explorateur. Tout le monde est rentré chez soi.

Le lendemain matin, l’équipe de conception ne pouvait plus sauvegarder de fichiers. Le répertoire affichait un accès « Modifier », pourtant chaque sauvegarde échouait. L’ingénieur a vérifié les paramètres de partage et n’a rien trouvé. Classique.

Le vrai problème : le nouveau répertoire n’avait pas d’entrées ACL POSIX par défaut, et le masque ACL sur certains répertoires était restrictif. Les fichiers créés par certaines applications obtenaient un mode limité par umask et aucune entrée ACL héritée. Les clients Windows présentaient une abstraction conviviale ; le côté Linux appliquait une réalité différente.

La correction n’a pas été une réécriture massive récursive des ACL. Ils ont défini les ACL par défaut sur les bons répertoires, corrigé les masques, activé setgid, puis touché seulement les points chauds où les fichiers étaient créés. La « mauvaise hypothèse » ne portait pas sur la syntaxe. Elle portait sur quel système était la source de vérité.

Mini-récit 2 : L’optimisation qui a mal tourné

Une équipe de stockage voulait accélérer l’ingestion nocturne dans un dataset partagé. Quelqu’un a proposé : « Exécutons l’ingestion en root, ça évitera les contrôles de permission et ira plus vite. » Ça a marché. L’ingestion finissait plus tôt. On a fêté avec la satisfaction discrète qu’on obtient seulement en gagnant des minutes sur un job que personne n’aime.

Deux semaines plus tard, des utilisateurs ont commencé à signaler l’impossibilité d’éditer certains fichiers. Ce n’était pas cohérent : un répertoire allait bien, l’autre non. Les tickets de support sont devenus des fils Slack, puis des réunions, puis encore plus de Slack. La productivité est morte par mille « pouvez-vous réessayer ? ».

La cause racine était subtile : des fichiers créés par root avaient des modes et ACL qui ne correspondaient pas au modèle de collaboration. Certains fichiers n’avaient pas d’entrées ACL nommées, et d’autres avaient des masques restrictifs à cause de la façon dont les ACL étaient appliquées par des scripts. L’ingestion était « plus rapide » parce qu’elle contournait les contraintes de correction.

Le retour arrière n’a pas été joli. Ils ont dû identifier les fichiers créés par l’utilisateur d’ingestion sur une plage de dates, restaurer la propriété de groupe correcte, et appliquer la politique ACL là où c’était nécessaire. La leçon est restée : les astuces de performance qui touchent l’identité et les permissions sont un instrument de dette avec intérêts composés.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation avait l’habitude disciplinée suivante : avant tout grand changement de permissions, ils capturaient les ACL récursivement dans un fichier horodaté et faisaient un snapshot du système de fichiers si possible. C’était écrit dans leur modèle de changement, et tout le monde respectait parce que la rotation d’astreinte était une souffrance partagée.

Lors d’une migration, un script destiné à corriger la propriété de groupe s’est lancé sur le mauvais point de montage. Il a changé la propriété de groupe sur un partage en production utilisé par plusieurs équipes. Le monitoring n’a pas hurlé ; les problèmes de permissions ressemblent rarement à des pics CPU. Les utilisateurs, eux, ont hurlé, ce qui est un signal moins lisible par les machines.

Parce qu’ils avaient la sauvegarde ACL avant changement et un snapshot, la récupération a été mécanique : remonter en lecture seule brièvement, restaurer les ACL, revenir en arrière sur le snapshot pour le sous-arbre affecté, puis réappliquer le changement voulu avec un périmètre corrigé. L’interruption n’était pas nulle, mais elle a été circonscrite. Pas d’archéologie, pas d’essais-erreurs.

Ce qui les a sauvés n’était pas de l’héroïsme. C’était l’ennui : une checklist, un artefact de retour arrière, et le refus de traiter « les permissions » comme trop simple pour nécessiter des garde-fous.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom : « L’utilisateur a rwx sur le répertoire mais ne peut toujours pas créer de fichiers »

Cause racine : Le masque ACL bride les permissions effectives (mask::r-x), ou l’utilisateur n’a pas l’écriture effective sur le répertoire.

Correctif : Inspectez avec getfacl et recherchez #effective. Ajustez le masque : setfacl -m m::rwx DIR et si nécessaire setfacl -m d:m::rwx DIR.

2) Symptom : « Les nouveaux fichiers ont le mauvais groupe »

Cause racine : Bit setgid manquant sur les répertoires, ou l’application crée ailleurs sans setgid.

Correctif : chmod g+s DIR. Confirmez via stat et testez la création en tant qu’utilisateur normal.

3) Symptom : « Tout semble correct sur Linux, mais les utilisateurs Windows ne peuvent pas éditer »

Cause racine : Mismatch de mapping des ACL Samba, xattrs non préservés, ou Windows attend des sémantiques d’héritage que les defaults POSIX ne fournissent pas.

Correctif : Validez les ACL POSIX par défaut sur les répertoires ; assurez-vous que le partage est configuré de manière cohérente ; confirmez le support des xattrs et que la copie/migration a préservé les ACL.

4) Symptom : « Après chmod -R, l’accès s’est empiré »

Cause racine : Les bits de mode ont changé mais les ACL restent ; chmod peut interagir avec le masque ACL et supprimer des chemins d’accès voulus.

Correctif : Arrêtez le chmod récursif sur les arbres gérés par ACL. Réappliquez la politique ACL prévue sur les répertoires et corrigez les masques. Restaurez depuis la sauvegarde ACL si vous en avez une.

5) Symptom : « Root ne peut pas réparer sur NFS »

Cause racine : Le root squashing mappe root sur un UID anonyme, empêchant les changements de propriété.

Correctif : Faites la réparation des permissions côté serveur (pas sur le montage client), ou ajustez la politique d’export NFS délibérément et temporairement avec contrôle de changement.

6) Symptom : « Certains répertoires sont inscriptibles ; d’autres identiques ne le sont pas »

Cause racine : ACL par défaut incohérentes entre répertoires, souvent dues à des migrations partielles ou des corrections ad hoc.

Correctif : Comparez avec getfacl un répertoire bon et un mauvais. Normalisez les defaults des répertoires ; évitez de toucher aux fichiers historiques sauf si nécessaire.

Listes de contrôle / plan étape par étape

Plan étape par étape pour une correction en masse sûre

1. Clarifier le modèle : décider quels groupes/utilisateurs doivent avoir lecture/écriture, et quels répertoires nécessitent un comportement d’héritage.
2. Capturer les artefacts de retour arrière : snapshot si disponible ; sinon getfacl -R -p dans un fichier.
3. Confirmer le chemin d’accès : local vs Samba vs NFS ; confirmer le mapping d’IDs et l’appartenance aux groupes.
4. Choisir un sous-arbre pilote : un dossier de projet, pas tout le partage.
5. Corriger l’héritage sur les répertoires : setgid + entrées ACL par défaut + masques par défaut.
6. Corriger les masques ACL des répertoires : s’assurer que les permissions effectives correspondent à l’intention.
7. Retester avec des actions réelles : créer, renommer, supprimer, éditer, et créer depuis l’application (pas seulement touch).
8. Normaliser la propriété de groupe où nécessaire : privilégier chgrp avec des expressions find limitées.
9. Seulement ensuite envisager des opérations récursives : quand vous pouvez articuler le rayon d’impact et disposez d’un retour arrière.
10. Avancer méthodiquement : appliquer le même schéma de correction au sous-arbre suivant ; ne pas improviser par répertoire.
11. Documenter les règles : attentes setgid, entrées ACL par défaut, et raison des masques tels qu’ils sont.
12. Garde-fous : un job d’audit périodique qui signale les répertoires sans setgid ou sans ACL par défaut.

Checklist pré-changement (imprimable dans votre tête)

• Ai-je un snapshot ou une sauvegarde ACL ?
• Sais-je quel protocole utilisent les utilisateurs (Samba/NFS/local) ?
• Ai-je reproduit en tant que vrai utilisateur avec sudo -u ?
• Ai-je vérifié le masque ACL et les permissions effectives ?
• Est-ce que je change des répertoires (héritage) avant de toucher aux fichiers (symptômes) ?
• Utilisé-je find ciblé au lieu de -R par habitude ?

Checklist post-changement (prouver que c’est corrigé)

• Créer un fichier, un répertoire, et renommer les deux en tant qu’utilisateur affecté.
• Vérifier que la propriété de groupe des nouveaux objets correspond à l’attendu (setgid fonctionne).
• Vérifier qu’un deuxième groupe collaboratif peut accéder si c’est dans la politique (ACL par défaut fonctionne).
• Vérifier un « répertoire sensible » connu pour s’assurer que vous n’avez pas élargi l’accès.
• Conserver la sauvegarde ACL/snapshot jusqu’à la fin du prochain cycle métier.

FAQ

1) Que signifie « prendre la propriété » dans le contexte d’un dossier partagé ?

Généralement : définir un propriétaire administratif cohérent (souvent root ou un compte de service) tout en utilisant des groupes/ACL pour accorder l’accès aux utilisateurs. La propriété sert au contrôle ; les ACL servent à la collaboration.

2) Pourquoi chmod semble parfois « casser » les permissions ACL ?

Parce que ACL et bits de mode interagissent. Le masque ACL peut changer les permissions effectives, et certaines opérations chmod peuvent altérer le masque. Si vous gérez l’accès avec des ACL, traitez chmod comme un outil chirurgical, pas comme un choix de vie récursif.

3) Comment préserver l’héritage pour les nouveaux fichiers ?

Sur Linux : utilisez setgid sur les répertoires pour l’héritage de groupe, et les ACL par défaut pour l’héritage des permissions. Vérifiez les entrées de masque par défaut pour que les permissions héritées soient réellement effectives.

4) Dois-je appliquer des ACL récursivement à chaque fichier ?

Pas par défaut. Corrigez d’abord les defaults des répertoires ; ils influencent le contenu futur. La correction récursive des fichiers existants est parfois nécessaire après une migration, mais elle augmente le risque et le temps d’exécution, et peut facilement sur-exposer des données.

5) J’ai exécuté chown -R et maintenant des applis échouent. Quel est le rollback le plus rapide ?

Si vous avez pris un snapshot, restaurez-le pour le sous-arbre affecté. Sinon, restaurez les ACL depuis votre sauvegarde getfacl puis corrigez la propriété en utilisant des règles ciblées. Si vous n’avez ni l’un ni l’autre, vous reconstruisez la politique par inférence—prévoyez du temps.

6) Pourquoi un utilisateur peut-il lister un répertoire mais pas accéder aux fichiers à l’intérieur ?

Lister requiert la lecture sur le répertoire ; accéder à un nom spécifique requiert l’exécution sur le répertoire et les permissions appropriées sur le fichier. L’absence de x sur un répertoire parent est un écueil courant.

7) Quelle est la différence entre une entrée ACL et le masque ACL ?

Les entrées expriment les permissions prévues pour des utilisateurs/groupes. Le masque est le maximum de permissions effectives pour les utilisateurs/groupes nommés et la classe group. Si le masque est restrictif, les entrées ne se comporteront pas comme prévu.

8) Comment l’héritage Samba/Windows se rapporte-t-il aux ACL par défaut Linux ?

Samba peut mapper les ACL Windows vers des ACL POSIX et/ou stocker des métadonnées plus riches dans des xattrs. L’« héritage » Windows ne se traduit pas toujours proprement. Sur Linux, les ACL par défaut sur les répertoires sont l’analogue le plus proche pour l’héritage des nouveaux objets.

9) Est-il sûr de corriger les permissions pendant que les utilisateurs sont actifs ?

Parfois. Les changements d’ACL/default de répertoire sont généralement sûrs mais peuvent provoquer des échecs transitoires si vous retirez l’accès brièvement. Les gros changements récursifs augmentent le risque et la charge. Si c’est critique pour l’activité, faites une fenêtre contrôlée et préparez le rollback.

Conclusion : prochaines étapes à effectuer réellement

Si vous regardez un arbre de permissions en désordre, ne commencez pas par la récursivité. Commencez par la vérité : confirmez l’identité, confirmez la sémantique de montage, confirmez les ACL effectives (en particulier les masques), puis corrigez l’héritage au niveau des répertoires. C’est là que se trouve la stabilité.

Étapes pratiques :

1. Choisissez un répertoire problématique et exécutez : namei -l, stat, getfacl, et un test de création en tant que vrai utilisateur.
2. Sauvegardez les ACL du sous-arbre avant de changer quoi que ce soit d’important.
3. Activez setgid et définissez les ACL par défaut sur les répertoires de collaboration ; corrigez les masques pour que « accordé » signifie « effectif ».
4. Scopez les changements de propriété/groupe avec des prédicats find ; préférez chgrp à chown quand c’est possible.
5. Après l’incident, consignez la politique voulue et ajoutez un job d’audit pour détecter la dérive avant la prochaine migration.

Les permissions ne sont pas difficiles parce que Linux est difficile. Elles sont difficiles parce que les humains sont incohérents, et le stockage se souvient de tout.