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 ou à un héritage manquant

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.

Imaginez un immeuble. Les permissions classiques, c’est comme avoir une seule clé pour les résidents et une autre pour les visiteurs. Les ACL, c’est un badge nominatif : chaque personne a exactement les accès dont elle a besoin, pièce par pièce.

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)

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. 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--.

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

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

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:rw /srv/webapp
   setfacl -m u:carol:r /srv/webapp

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

3. Vérifiez l’état complet :

   getfacl /srv/webapp

   # file: srv/webapp
   # owner: alice
   # group: dev
   user::rwx
   user:bob:rw-
   user:carol:r--
   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 :

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

Restaurer :

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

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

Symptôme	Cause probable	Solution
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

Contrôle de connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

5 min.

80% 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.
• 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.
• Les default ACL sur un répertoire assurent l’héritage automatique pour les nouveaux fichiers.
• Sauvegardez les ACL séparément (getfacl -R > fichier) avant toute migration ou restauration.
• Appliquez le moindre privilège : ne donnez que les droits nécessaires, auditez régulièrement les accès.

Prochaines étapes

Utilisateurs, groupes et permissions Maîtriser les permissions POSIX classiques avant d'aller plus loin avec les ACL.

Gérer les groupes et utilisateurs Créer, modifier et supprimer les comptes et groupes système.

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

Comprendre et utiliser sudo Déléguer des droits d'administration de manière contrôlée.

×

📖 Voir la documentation →