Linux sans magie #13 — ACL par défaut : maîtriser les permissions héritées dans un répertoire
Comprendre les ACL par défaut sous Linux, leur héritage, leur interaction avec umask et le rôle de la mask ACL.
Vous avez configuré un répertoire partagé.
Vous avez attribué les bons droits au groupe. Vous avez même ajouté une ACL avec setfacl.
Puis un utilisateur crée un nouveau fichier… et les permissions ne correspondent plus à ce que vous attendiez.
Pourquoi ?
Parce qu'une ACL d'accès appliquée au répertoire ne définit pas automatiquement les ACL des futurs fichiers.
Pour cela, Linux dispose des default ACLs.
1. ACL d'accès et default ACL : deux rôles différents
Prenons un répertoire :
mkdir ~/projet
Une ACL classique :
setfacl -m g:formateurs:rwx ~/projet
accorde au groupe formateurs des droits sur le répertoire lui-même.
Mais cela ne suffit pas à définir les ACL des objets qui seront créés à l'intérieur.
Une default ACL, au contraire, sert de modèle pour initialiser les ACL des nouveaux objets créés dans un répertoire. Seuls les répertoires peuvent posséder une default ACL.
2. Créer une default ACL
Supposons que nous voulions donner au groupe formateurs des droits sur les futurs objets du répertoire :
setfacl -d -m g:formateurs:rwx ~/projet
L'option :
-d
signifie :
--default
Elle indique à setfacl que nous travaillons sur la default ACL du répertoire.
Vérifions :
getfacl ~/projet
On pourra notamment observer :
default:user::rwx
default:group::r-x
default:group:formateurs:rwx
default:mask::rwx
default:other::r-x
Les entrées commençant par default: constituent la default ACL. getfacl affiche normalement à la fois l'ACL d'accès et la default ACL lorsqu'elle existe.
3. Que se passe-t-il lorsqu'un fichier est créé ?
Créons maintenant :
touch ~/projet/document.txt
Puis :
getfacl ~/projet/document.txt
Le nouveau fichier reçoit une ACL d'accès dérivée de la default ACL du répertoire parent.
C'est une distinction essentielle :
répertoire
│
├── Access ACL
│ → contrôle l'accès au répertoire
│
└── Default ACL
→ sert à initialiser l'ACL des nouveaux objets
Le fichier créé ne possède pas lui-même une « default ACL ».
Il possède une access ACL héritée du modèle défini par son répertoire parent.
4. Et les sous-répertoires ?
Créons :
mkdir ~/projet/module1
Puis :
getfacl ~/projet/module1
Un nouveau sous-répertoire peut recevoir l'ACL issue de son parent et conserver une default ACL, permettant à son tour de transmettre ce modèle aux objets créés en dessous.
On obtient donc une propagation naturelle :
projet
├── module1
│ ├── fichier1
│ └── fichier2
│
└── module2
└── fichier3
À condition que les default ACLs appropriées soient présentes sur les répertoires concernés.
5. Attention à umask
C'est ici qu'une confusion fréquente apparaît.
Sans default ACL, la création d'un fichier repose notamment sur :
mode demandé par l'application
+
umask
Mais lorsqu'une default ACL existe sur le répertoire parent, Linux suit un autre mécanisme : le nouvel objet hérite de cette ACL, puis les permissions sont limitées par le mode demandé lors de sa création. Le umask n'est alors pas appliqué comme masque supplémentaire.
Cela explique pourquoi :
umask
ne suffit pas toujours à expliquer les permissions observées dans un environnement utilisant des ACL.
Le bon diagnostic devient :
getfacl repertoire
puis :
getfacl fichier
6. Pourquoi rwx ne signifie pas toujours rwx sur un nouveau fichier
Supposons que la default ACL contienne :
default:group:formateurs:rwx
Vous pourriez vous attendre à obtenir systématiquement :
group:formateurs:rwx
avec les trois permissions effectives.
Mais une application qui crée un fichier ordinaire demande généralement un mode ne comportant pas le bit d'exécution.
La default ACL ne peut pas ajouter une permission que le mode de création ne permet pas. Le résultat peut donc être limité, par exemple à :
group:formateurs:rw-
C'est normal : la default ACL constitue un modèle, mais le mode demandé lors de la création reste une limite.
7. Le rôle de mask
Avec des ACL étendues, vous rencontrerez également :
mask::rwx
La ACL mask représente le maximum de permissions effectives accordables au groupe propriétaire ainsi qu'aux utilisateurs et groupes nommés concernés.
Par exemple :
group:formateurs:rwx
mask::r-x
signifie que l'entrée demande rwx, mais que ses droits effectifs sont limités par le masque.
getfacl peut alors afficher :
group:formateurs:rwx #effective:r-x
Le propriétaire du fichier et l'entrée other ne sont pas limités par cette ACL mask.
8. Modifier une default ACL
Pour ajouter ou modifier une entrée :
setfacl -d -m g:formateurs:rwx ~/projet
Pour travailler explicitement avec la syntaxe default: :
setfacl -m d:g:formateurs:rwx ~/projet
Les deux formes permettent de manipuler les entrées par défaut.
9. Supprimer la default ACL
Pour retirer toutes les entrées de default ACL d'un répertoire :
setfacl -k ~/projet
ou :
setfacl --remove-default ~/projet
Puis vérifiez :
getfacl ~/projet
L'option -k supprime la default ACL sans supprimer l'ACL d'accès du répertoire.
Petit lab
Créez un environnement isolé :
mkdir -p ~/linux-sans-magie-acl-default
cd ~/linux-sans-magie-acl-default
mkdir partage
Configurez une default ACL pour votre utilisateur :
setfacl -d -m u:"$USER":rwx partage
Observez :
getfacl partage
Créez ensuite :
touch partage/fichier.txt
mkdir partage/sous-repertoire
Comparez :
getfacl partage/fichier.txt
getfacl partage/sous-repertoire
L'objectif est d'observer la différence entre ACL d'accès, default ACL et ACL effectivement attribuée aux nouveaux objets.
Nettoyage / rollback
cd
rm -rf ~/linux-sans-magie-acl-default
Aucun fichier système n'a été modifié.
À retenir
Une Access ACL contrôle les droits sur l'objet existant.
Une Default ACL n'existe que sur un répertoire et sert à déterminer les ACL initiales des nouveaux objets créés à l'intérieur.
Avec :
setfacl -d
vous ne modifiez donc pas simplement les permissions actuelles.
Vous définissez une politique de permissions pour les créations futures.
Et lorsqu'un ls -l ou un umask ne suffit plus à expliquer les droits observés, le réflexe devient :
getfacl
Parce qu'une fois encore, Linux n'a rien fait de magique : il applique simplement une couche de permissions que rwx seul ne montre pas entièrement.