Affiner les permissions avec les ACL

Trois développeurs travaillent sur /srv/projet. Alice doit lire et écrire, Bob seulement lire, et tout le reste de l'équipe n'a aucun accès. Avec les permissions POSIX classiques (propriétaire / groupe / autres), c'est impossible sans créer un groupe dédié par combinaison de droits.

Les ACL (Access Control Lists) résolvent ce problème. Elles permettent d'attribuer des permissions par utilisateur et par groupe, indépendamment du propriétaire et du groupe principal. C'est le mécanisme standard du noyau Linux pour gérer des droits fins sur ext4, XFS et Btrfs, les trois systèmes de fichiers les plus courants en production.

Sans ACL, l'administrateur contourne le problème en multipliant les groupes, en relâchant les droits other, ou en utilisant sudo à outrance, autant de pratiques qui augmentent la surface d'exposition.

Ce que vous allez apprendre

• Distinguer quand les ACL sont nécessaires et quand les permissions classiques suffisent
• Lire une ACL avec getfacl et la modifier avec setfacl
• Poser des ACL par défaut pour que les nouveaux fichiers héritent des bons droits
• Diagnostiquer un problème d'accès lié au mask, à un héritage manquant ou à un droit de traversée absent sur le chemin

Permissions classiques vs ACL : quand basculer ?

Avant de poser des ACL, il faut savoir si elles sont réellement nécessaires. Les permissions POSIX classiques couvrent la majorité des cas. Les ACL interviennent quand le modèle propriétaire/groupe/autres ne suffit plus.

Le modèle POSIX n'expose que trois jeux de droits par fichier : propriétaire, groupe, et tous les autres. Il ne sait donc pas accorder un accès distinct à deux utilisateurs qui ne partagent aucun groupe, sans en créer un pour l'occasion. Les ACL lèvent cette limite en attachant au fichier une liste d'entrées nominatives, une par utilisateur ou par groupe.

Situation	Permissions classiques	ACL
Un propriétaire, un groupe, accès uniforme	Suffisant	Inutile
Deux utilisateurs dans des groupes différents doivent accéder au même fichier	Créer un groupe dédié	Plus simple avec ACL
Chaque utilisateur a un niveau d'accès différent sur le même répertoire	Impossible	Seule solution
Un prestataire externe doit lire un dossier sans rejoindre un groupe	Risqué (élargir other)	ACL sur l'utilisateur
Héritage automatique de droits pour les nouveaux fichiers	umask limité	Default ACL

Glissez pour voir

Règle pratique

Si un chmod et un groupe bien choisi résolvent le problème, ne posez pas d'ACL. Les ACL ajoutent de la complexité ; réservez-les aux cas où les permissions classiques atteignent leurs limites.

Prérequis

• Connaître les permissions POSIX classiques (chmod, chown, propriétaire/groupe/autres)
• Savoir gérer les utilisateurs et groupes
• Accès root ou sudo sur la machine
• Système de fichiers compatible ACL (ext4, XFS, Btrfs)
• Le paquet acl, qui fournit getfacl et setfacl

Le paquet acl n'est pas toujours installé

Sur une AlmaLinux 10 ou une RHEL 10 minimale, rpm -q acl répond package acl is not installed et les deux commandes sont introuvables. Rien ne le laisse deviner : aucun paquet du système de base ne dépend d'acl. Vérifiez avant de commencer.

Debian / Ubuntu

sudo apt install acl

RHEL / AlmaLinux / Fedora

sudo dnf install acl

Compatibilité système de fichiers

Les ACL sont supportées nativement par ext4, XFS et Btrfs. Sur ext3, elles nécessitent l'option de montage acl. FAT32 et exFAT ne les supportent pas.

Vérifier que les ACL sont actives

Sur les distributions modernes, les ACL sont activées par défaut sur ext4, XFS et Btrfs. Vérifiez tout de même avant de commencer.

Debian / Ubuntu (ext4)

tune2fs -l /dev/sda1 | grep "Default mount options"

Sortie attendue :

Default mount options:    user_xattr acl

Si acl n'apparaît pas, ajoutez-le dans /etc/fstab :

UUID=xxxxxxxx-xxxx  /  ext4  defaults,acl  0  1

Puis remontez :

mount -o remount /

RHEL / Rocky / Fedora (XFS)

XFS active les ACL par défaut, aucune configuration nécessaire. Vérifiez :

mount | grep " / "

Sortie attendue :

/dev/mapper/rl-root on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,noquota)

Les ACL sont toujours actives sur XFS, pas d'option à ajouter.

Vérification : créez un test rapide pour confirmer que les ACL fonctionnent :

touch /tmp/test-acl
setfacl -m u:nobody:r /tmp/test-acl
getfacl /tmp/test-acl | grep "user:nobody"

Si la sortie affiche user:nobody:r--, les ACL sont opérationnelles.

rm /tmp/test-acl

Premier usage : poser et lire une ACL

Avant d'entrer dans la théorie, voyons le geste de base.

Scénario : le fichier /srv/rapport.txt appartient à alice. Vous devez donner l'accès en lecture à bob, sans modifier le groupe du fichier.

1. Posez l'ACL :

   setfacl -m u:bob:r /srv/rapport.txt

2. Vérifiez avec getfacl :

   getfacl /srv/rapport.txt

   Sortie :

   srv/rapport.txt

   # owner: alice
   # group: alice
   user::rw-
   user:bob:r--
   group::r--
   mask::r--
   other::---

3. Confirmez avec ls -l, le + à la fin des permissions indique une ACL active :

   ls -l /srv/rapport.txt

   -rw-r-----+ 1 alice alice 42 avr  5 10:00 /srv/rapport.txt

bob peut maintenant lire le fichier, à une condition que l'exemple ci-dessus masque : il doit pouvoir atteindre le fichier.

Une ACL sur un fichier ne suffit pas à le lire

C'est le malentendu des ACL, et il coûte des heures. Une ACL décide de ce qu'on a le droit de faire sur un fichier, pas du droit d'arriver jusqu'à lui. Pour ouvrir /srv/projet/rapport.txt, le noyau vérifie d'abord le droit de traversée (x) sur /, puis sur /srv, puis sur /srv/projet. Un seul maillon manquant et la lecture échoue, ACL ou pas.

L'exemple précédent fonctionne uniquement parce que /srv est livré en 755, donc traversable par tout le monde. Déplacez le même fichier sous un répertoire réaliste et le résultat s'inverse :

sudo chmod 750 /srv/projet          # root:root, personne d'autre ne traverse
sudo -u bob cat /srv/projet/rapport.txt

cat: /srv/projet/rapport.txt: Permission denied

L'ACL est pourtant intacte : getfacl affiche toujours user:bob:r--. Ce qui manque, c'est le x sur le répertoire parent. Accordez-le, et la lecture passe immédiatement :

sudo setfacl -m u:bob:x /srv/projet
sudo -u bob cat /srv/projet/rapport.txt

rapport trimestriel

Sur un répertoire, r sans x ne sert à rien

Retenez la distinction, elle revient sans arrêt : sur un répertoire, r autorise à lister les noms, x autorise à entrer et à ouvrir ce qu'il contient. Un utilisateur qui n'a que r voit les noms de fichiers avec ls et se prend un Permission denied dès qu'il en ouvre un.

Sur un répertoire, la bonne ACL en lecture seule est donc rx, jamais r seul. Et en écriture, rwx, jamais rw.

alice conserve la lecture et l'écriture. Les autres utilisateurs n'ont aucun accès.

Comprendre la structure d'une ACL

Maintenant que vous avez vu le geste, décortiquons ce que getfacl affiche.

Les entrées d'une ACL

Chaque ligne de la sortie de getfacl est une entrée ACL :

Entrée	Signification
user::rw-	Permissions du propriétaire du fichier
user:bob:r--	Permissions spécifiques pour l'utilisateur bob
group::r--	Permissions du groupe propriétaire
group:dev:rw-	Permissions spécifiques pour le groupe dev
mask::rw-	Permissions maximales pour les entrées nommées
other::---	Permissions pour tous les autres

Glissez pour voir

Le mask : le plafond de permissions

Le mask est le concept le plus important (et le plus mal compris) des ACL. Il agit comme un plafond : même si une entrée accorde rwx, les permissions effectives sont limitées par le mask.

Exemple :

user:bob:rw-          #effective:r--
mask::r--

Bob a rw- dans son entrée ACL, mais le mask est à r--. Ses permissions effectives sont donc uniquement r--.

ls -l affiche le mask, pas le groupe

Conséquence directe et rarement dite : dès qu'un + est présent, la position du groupe dans ls -l ne montre plus les droits du groupe propriétaire, mais le mask. Sur un fichier en 640 auquel on ajoute une entrée pour bob :

setfacl -m u:bob:rw /srv/m.txt
getfacl -c /srv/m.txt

user::rw-
user:bob:rw-
group::r--
mask::rw-
other::---

Le groupe propriétaire n'a que r--. Et pourtant :

ls -l /srv/m.txt

-rw-rw----+ 1 alice alice 2 juil. 23 08:36 /srv/m.txt

Les rw du milieu sont le mask, pas group::. Un administrateur qui lit cette ligne conclut que le groupe peut écrire : c'est faux. Seul getfacl dit la vérité sur un fichier porteur du +.

Piège classique

chmod modifie le mask des ACL, pas les entrées individuelles. Si vous lancez chmod g=r fichier sur un fichier avec ACL, le mask passe à r-- et toutes les permissions nommées sont plafonnées à lecture seule, même si setfacl leur avait accordé l'écriture.

Vérification : après chaque setfacl, vérifiez le mask :

getfacl fichier | grep mask

Si le mask est trop restrictif, corrigez-le :

setfacl -m m::rwx fichier

ACL par défaut (héritage)

Sur un répertoire, vous pouvez poser des default ACL. Chaque nouveau fichier ou sous-répertoire créé à l'intérieur hérite automatiquement de ces ACL.

Les entrées par défaut commencent par default: dans la sortie de getfacl :

default:user::rwx
default:user:bob:rw-
default:group::r-x
default:mask::rwx
default:other::r-x

Rappel

Les ACL par défaut ne s'appliquent qu'aux répertoires. Elles n'ont aucun effet sur un fichier simple.

Poser et modifier des ACL avec setfacl

setfacl modifie la liste attachée au fichier, sans toucher aux permissions POSIX affichées par ls -l. Un fichier porteur d'ACL se repère au + en fin de champ de permissions ; seul getfacl en montre le détail.

Ajouter ou modifier une entrée

Pour un utilisateur :

setfacl -m u:bob:rw /srv/projet/config.yml

Pour un groupe :

setfacl -m g:dev:r /srv/projet/config.yml

Vérification :

getfacl /srv/projet/config.yml

Poser des ACL par défaut sur un répertoire

Pour que tous les fichiers créés dans /srv/projet héritent des droits de bob :

setfacl -d -m u:bob:rw /srv/projet

Ne soyez pas surpris par ce que getfacl affiche ensuite : une seule entrée par défaut en fait apparaître cinq. Sur un répertoire qui n'en portait aucune, un setfacl -d -m g:dev:rw produit ceci :

default:user::rwx
default:group::r-x
default:group:dev:rw-
default:mask::rwx
default:other::r-x

Le noyau complète le jeu, parce qu'une ACL par défaut doit être complète pour être applicable : il lui faut un propriétaire, un groupe, un mask et un « autres ». Les quatre entrées supplémentaires reprennent simplement les permissions classiques du répertoire. Vous n'avez rien fait de travers.

Vérification : créez un fichier et contrôlez ses ACL :

touch /srv/projet/test.txt
getfacl /srv/projet/test.txt | grep "user:bob"

Sortie attendue : user:bob:rw-.

Supprimer une entrée ACL

Retirer les droits spécifiques de bob :

setfacl -x u:bob /srv/projet/config.yml

Supprimer toutes les ACL d'un fichier

Pour revenir aux permissions classiques :

setfacl -b /srv/projet/config.yml

Vérification : ls -l ne doit plus montrer le + :

ls -l /srv/projet/config.yml

Appliquer des ACL en masse (récursif)

Pour poser une ACL sur tout un répertoire et son contenu :

setfacl -R -m u:bob:rw /srv/projet

Pour poser des ACL par défaut sur tous les sous-répertoires :

setfacl -R -d -m u:bob:rw /srv/projet

Cas réel : espace projet partagé

Voici un scénario complet d'administration. Trois personnes travaillent sur /srv/webapp :

• alice (développeuse) : lecture, écriture, exécution
• bob (intégrateur) : lecture et écriture
• carol (auditrice externe) : lecture seule

1. Créez le répertoire et posez les ACL :

   mkdir -p /srv/webapp
   chown alice:dev /srv/webapp
   chmod 750 /srv/webapp
   setfacl -m u:bob:rwx /srv/webapp
   setfacl -m u:carol:rx /srv/webapp

   Notez le x sur les deux entrées. C'est le répertoire qu'on traite ici, et sans lui bob et carol verraient les noms de fichiers sans pouvoir en ouvrir un seul. Le piège est décrit plus haut, et il se vérifie en une commande : avec u:carol:r seul, sudo -u carol cat /srv/webapp/app.py répond Permission denied alors que sudo -u carol ls /srv/webapp affiche bien app.py.

2. Posez les ACL par défaut pour l'héritage :

   setfacl -d -m u:alice:rwx /srv/webapp
   setfacl -d -m u:bob:rw /srv/webapp
   setfacl -d -m u:carol:r /srv/webapp

   Ici, pas de x : ces entrées s'appliqueront aux fichiers créés dans le répertoire, et un fichier de données n'a pas à être exécutable. Les sous-répertoires créés hériteront quant à eux du x par le jeu des permissions par défaut.

3. Vérifiez l'état complet :

   getfacl /srv/webapp

   # file: srv/webapp
   # owner: alice
   # group: dev
   user::rwx
   user:bob:rwx
   user:carol:r-x
   group::r-x
   mask::rwx
   other::---
   default:user::rwx
   default:user:alice:rwx
   default:user:bob:rw-
   default:user:carol:r--
   default:group::r-x
   default:mask::rwx
   default:other::---

4. Testez l'héritage, créez un fichier et vérifiez :

   su - alice -c "touch /srv/webapp/app.py"
   getfacl /srv/webapp/app.py

   Les entrées pour bob et carol doivent apparaître automatiquement.

Sauvegarde et restauration des ACL

Lors d'une migration ou d'une sauvegarde, les outils standard (cp, tar, rsync) ne préservent pas toujours les ACL. Sauvegardez-les séparément.

Sauvegarder, avec l'option -p qui n'est pas facultative :

getfacl -pR /srv/webapp > /root/acl-webapp.bak

Restaurer :

setfacl --restore=/root/acl-webapp.bak

Sans -p, la sauvegarde ne se restaure pas

C'est le piège qui ne se voit qu'au pire moment. Un getfacl -R sans -p affiche d'abord un avertissement facile à manquer :

getfacl: Removing leading '/' from absolute path names

Il enregistre alors des chemins relatifs : la première ligne du fichier de sauvegarde est # file: srv/webapp et non # file: /srv/webapp. La restauration ne fonctionne dès lors que si on la lance depuis /. Depuis n'importe où ailleurs, elle échoue ligne par ligne :

setfacl: srv/webapp: No such file or directory

La sauvegarde paraît réussie le jour où on la crée, et se révèle inutilisable le jour où on en a besoin. Vérifiez toujours la première ligne du fichier : elle doit commencer par # file: /.

rsync et ACL

Avec rsync, ajoutez l'option -A pour préserver les ACL : rsync -avA /srv/webapp/ /backup/webapp/. Sans -A, les ACL sont perdues silencieusement.

Sécurité : moindre privilège et audit

Les ACL sont un outil puissant, mais mal utilisées, elles élargissent la surface d'exposition au lieu de la réduire.

Principe du moindre privilège

• N'accordez que les droits nécessaires : si bob n'a besoin que de lire, ne donnez pas rw.
• Préférez les permissions par groupe plutôt que par utilisateur quand plusieurs personnes ont le même besoin.
• Supprimez les ACL d'un prestataire dès la fin de sa mission.

Audit régulier

Programmez un contrôle périodique des ACL sur les répertoires sensibles :

getfacl -R /srv/webapp | grep "user:" | sort -u

Cela liste tous les utilisateurs ayant des droits spécifiques. Comparez avec la liste des accès autorisés.

Interaction avec SELinux et AppArmor

Les ACL opèrent au niveau du système de fichiers. Si SELinux ou AppArmor est actif, un accès peut être refusé par le MAC (Mandatory Access Control) même si l'ACL l'autorise. Vérifiez les deux couches en cas de Permission denied inattendu.

Dépannage

Un Permission denied malgré une ACL correcte a presque toujours l'une de ces trois causes : la traversée du chemin, le mask, ou une couche MAC par-dessus. Les trois premières lignes du tableau les couvrent dans l'ordre où il faut les vérifier.

Symptôme	Cause probable	Solution
Permission denied alors que getfacl montre bien l'entrée	Pas de droit x sur un répertoire du chemin	namei -l /srv/projet/rapport.txt pour voir où ça bloque, puis setfacl -m u:<user>:x sur le parent
L'utilisateur voit les noms avec ls mais ne peut ouvrir aucun fichier	ACL en r seul sur un répertoire	Utiliser rx sur un répertoire, jamais r
setfacl: command not found	Paquet acl absent, cas d'AlmaLinux et RHEL minimales	sudo dnf install acl ou sudo apt install acl
setfacl --restore échoue sur No such file or directory	Sauvegarde faite sans -p, chemins relatifs	Refaire avec getfacl -pR, ou restaurer depuis /
ls -l montre des droits de groupe qui n'existent pas	La position du groupe affiche le mask dès qu'un + est présent	Lire getfacl, pas ls -l
setfacl: Operation not supported	Système de fichiers sans support ACL (FAT32, ancien ext3 sans option)	Vérifier tune2fs -l ou passer à ext4/XFS
Permission denied malgré ACL correcte	Le mask plafonne les droits	getfacl fichier | grep mask puis setfacl -m m::rwx fichier
Permission denied avec mask OK	SELinux ou AppArmor bloque	ausearch -m AVC -ts recent (SELinux) ou dmesg | grep apparmor
Nouveaux fichiers sans ACL héritées	Pas de default ACL sur le répertoire parent	setfacl -d -m u:bob:rw /srv/projet
chmod a cassé les ACL	chmod modifie le mask	Recréer le mask : setfacl -m m::rwx fichier
Le + disparaît après cp	cp sans -p ou --preserve=all	Utiliser cp -a ou rsync -A

Glissez pour voir

Mettre en pratique

Rien ne fixe mieux le rôle du mask que de le voir plafonner un droit sous vos yeux. Le lab vous fait construire un répertoire partagé avec setfacl, poser des default ACL pour l'héritage, puis contrôler chaque permission effective avec getfacl sur des comptes réels.

Lab pratique

Accorder des accès fins avec les ACL POSIX

$ dsoxlab run l2-acl-posix

Environnement : VM·Durée : ~25 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l2-acl-posix
dsoxlab check l2-acl-posix

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Les ACL complètent les permissions POSIX quand le modèle propriétaire/groupe/autres ne suffit plus.
• Le paquet acl n'est pas installé sur une AlmaLinux ou une RHEL minimale : vérifiez avant de commencer.
• Une ACL sur un fichier ne suffit pas à le lire : il faut le droit x de traversée sur chaque répertoire du chemin. Sur un répertoire, c'est rx en lecture et rwx en écriture, jamais r ni rw seuls.
• getfacl lit les ACL, setfacl les pose, toujours vérifier après chaque modification.
• Le mask est le plafond des permissions nommées. Un simple chmod peut le modifier et casser vos ACL sans avertissement.
• Dès qu'un + apparaît, ls -l affiche le mask à la place des droits du groupe. Seul getfacl dit la vérité.
• Les default ACL sur un répertoire assurent l'héritage automatique pour les nouveaux fichiers ; une seule entrée posée en fait apparaître cinq.
• Sauvegardez les ACL avec getfacl -pR, jamais -R seul : sans -p, les chemins sont relatifs et la restauration échoue hors de /.
• Appliquez le moindre privilège : ne donnez que les droits nécessaires, auditez régulièrement les accès.

Pour aller plus loin

• Capabilities Linux : Accorder des privilèges fins sans donner les droits root complets.

×

📖 Voir la documentation →