Linux sans magie #11 — ACL : donner un droit à un utilisateur sans chambouler toutes les permissions

Jusqu’ici, nous avons appris à raisonner avec trois catégories :

propriétaire | groupe | autres

Ce modèle couvre énormément de situations.

Mais imaginons maintenant ceci : un fichier appartient à Alice, son groupe doit conserver ses droits actuels, et nous voulons simplement permettre à Bob de le lire.

Nous pourrions changer de groupe, ouvrir davantage les permissions classiques ou réorganiser la propriété du fichier. Mais ce serait modifier beaucoup de choses pour répondre à un besoin très précis.

C’est justement là que les ACL, pour Access Control Lists, deviennent utiles.

Sous Linux, elles permettent de définir des droits plus fins pour des utilisateurs ou des groupes nommés, en complément des permissions classiques.

Objectif

À la fin de ce lab, vous saurez :

• reconnaître la présence d’une ACL ;
• lire le résultat de getfacl ;
• ajouter un droit à un utilisateur précis ;
• comprendre pourquoi le masque ACL peut modifier les droits réellement obtenus ;
• retirer proprement l’entrée ajoutée ;
• distinguer permissions classiques et ACL.

Nous resterons volontairement sur les ACL d’accès simples.

Les ACL par défaut, qui permettent notamment de définir les droits hérités dans un répertoire, viendront plus tard.

Avant de commencer : un détail important

Pour démontrer réellement qu’un utilisateur A peut donner un accès spécifique à un utilisateur B, il faut disposer de deux comptes utilisateur.

Nous n’allons pas créer automatiquement un nouvel utilisateur système pour ce lab.

Si votre machine possède déjà un second compte de test, vous pourrez réaliser toute la manipulation. Sinon, vous pourrez tout de même exécuter les commandes d’inspection et comprendre le mécanisme. Les commandes utilisant le second utilisateur seront clairement identifiées.

Autre point : les commandes getfacl et setfacl doivent être disponibles sur votre système. Leur disponibilité peut dépendre de la distribution et de l’installation des outils ACL.

Testez :

command -v getfacl
command -v setfacl

Si les commandes existent, leur chemin est affiché, par exemple :

/usr/bin/getfacl
/usr/bin/setfacl

Lab — préparer un fichier classique

Placez-vous dans votre répertoire personnel :

cd

Créez notre lab :

mkdir linux-sans-magie-lab
cd linux-sans-magie-lab

Créons un fichier :

echo "Document confidentiel de lab" > document.txt

Regardez ses permissions :

ls -l document.txt

Le résultat exact dépendra de votre utilisateur et de votre umask.

Pour notre raisonnement, imaginons :

-rw-r----- 1 alice equipe 29 Sep 10 09:00 document.txt

Nous avons :

rw- | r-- | ---

Donc :

• propriétaire : lecture et écriture ;
• groupe : lecture ;
• autres : aucun droit.

C’est le modèle que nous connaissons déjà.

Observer l’ACL actuelle

Exécutez :

getfacl document.txt

Vous devriez voir quelque chose de proche de :

# file: document.txt
# owner: alice
# group: equipe
user::rw-
group::r--
other::---

Cela ressemble presque exactement à nos permissions classiques, et c’est normal.

Les entrées correspondant au propriétaire, au groupe propriétaire et aux autres sont les entrées ACL de base. Une ACL devient réellement plus intéressante lorsqu’elle contient notamment un utilisateur ou un groupe nommé supplémentaire.

Ajouter un utilisateur précis

Supposons maintenant que nous disposions d’un second utilisateur appelé :

bob

Vérifiez d’abord qu’il existe réellement :

id bob

Si le compte n’existe pas, n’inventez pas un utilisateur et ne créez rien pour ce lab. Vous pouvez continuer la lecture sans exécuter les commandes concernant bob.

Si le compte existe, ajoutons-lui seulement le droit de lecture :

setfacl -m u:bob:r-- document.txt

La syntaxe peut se lire ainsi :

u:bob:r--

soit :

utilisateur : bob : lecture seule

setfacl -m sert à modifier l’ACL.

Vérifier ce qui vient de changer

Exécutez :

getfacl document.txt

Vous pourriez maintenant obtenir :

# file: document.txt
# owner: alice
# group: equipe
user::rw-
user:bob:r--
group::r--
mask::r--
other::---

Une nouvelle ligne apparaît :

user:bob:r--

Voilà notre ACL supplémentaire.

Nous n’avons pas changé le propriétaire, changé le groupe du fichier, ouvert les permissions aux autres, ni utilisé chmod 777.

Nous avons ajouté une règle spécifique pour Bob.

Et ls -l, que montre-t-il ?

Regardez à nouveau :

ls -l document.txt

Sur un système prenant en charge les ACL de cette manière, vous pourrez remarquer un + après les permissions :

-rw-r-----+ 1 alice equipe ... document.txt

Ce + indique que les droits ne se résument plus nécessairement aux trois blocs classiques affichés par ls -l.

C’est exactement la situation évoquée dans notre article sur Permission denied : ls -l peut être correct sans raconter toute l’histoire.

Comprendre le masque ACL

Vous avez probablement remarqué cette ligne :

mask::r--

Le masque ACL définit le maximum de droits effectifs pouvant être accordés à plusieurs catégories d’entrées, notamment les utilisateurs nommés, le groupe propriétaire et les groupes nommés.

Il ne limite pas de la même manière l’entrée du propriétaire du fichier ni l’entrée other.

Pour l’instant :

user:bob:r--
mask::r--

Bob demande r-- et le masque autorise r--. Les droits effectifs de Bob restent donc r--.

Provoquer une situation intéressante

Nous allons volontairement modifier le masque pour comprendre son rôle.

Exécutez :

setfacl -m m:--- document.txt

Puis :

getfacl document.txt

Vous pourriez voir :

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

Regardez attentivement :

user:bob:r--

semble toujours dire que Bob possède le droit de lecture.

Mais juste à côté :

#effective:---

nous indique que son droit réel est limité par le masque.

C’est une notion importante : une entrée ACL peut annoncer certains droits, tandis que le masque détermine les droits effectivement utilisables.

Restaurer le masque

Remettons un masque permettant la lecture :

setfacl -m m:r-- document.txt

Vérifiez :

getfacl document.txt

Bob devrait retrouver un droit effectif de lecture.

Que fait normalement setfacl avec le masque ?

Heureusement, vous n’avez généralement pas besoin de recalculer le masque manuellement à chaque modification.

Par défaut, setfacl recalcule l’entrée de masque lorsqu’une ACL étendue est modifiée, sauf comportement demandé explicitement par certaines options. L’option -n permet notamment d’empêcher ce recalcul automatique.

Pour notre série, le bon réflexe reste donc :

setfacl ...
getfacl ...

On modifie, puis on observe le résultat réel.

Tester avec le second utilisateur

Si vous disposez réellement du compte de test bob et d’une méthode normale pour ouvrir une session avec lui, vous pouvez tester la lecture du fichier.

Attention : le simple fait d’avoir une ACL sur document.txt ne garantit pas que Bob puisse atteindre ce fichier.

Nous avons appris dans le #9 que tous les répertoires du chemin doivent également être traversables.

C’est particulièrement important si votre lab se trouve dans votre répertoire personnel, qui peut être privé.

Par exemple :

ls -ld "$HOME"

Si Bob ne peut pas traverser votre répertoire personnel, l’ACL sur le fichier ne suffira pas.

Ce n’est pas un défaut des ACL. C’est simplement notre règle habituelle :

accès au chemin
+
droits sur l’objet final
=
opération possible

Pour cette raison, nous ne transformerons pas ce lab débutant en exercice multi-utilisateur complexe avec changement des permissions du $HOME.

Le point à retenir ici est le fonctionnement de l’ACL elle-même.

Retirer uniquement l’entrée de Bob

Nous voulons maintenant revenir en arrière.

Au lieu de supprimer toutes les ACL sans réfléchir, retirons précisément l’entrée que nous avons ajoutée :

setfacl -x u:bob document.txt

Puis :

getfacl document.txt

L’entrée user:bob:r-- doit avoir disparu.

L’option -x permet de supprimer des entrées ACL sélectionnées.

Et si je veux supprimer toutes les ACL étendues ?

setfacl fournit aussi :

setfacl -b document.txt

Cette option retire les entrées ACL étendues tout en conservant les entrées ACL de base correspondant au propriétaire, au groupe et aux autres.

Dans notre lab, nous préférons :

setfacl -x u:bob document.txt

parce qu’elle exprime exactement notre intention.

C’est le même principe que dans les articles précédents : corriger ou retirer le minimum nécessaire.

ACL ou chmod ?

Les deux outils ne répondent pas exactement au même problème.

chmod est idéal lorsque notre besoin correspond au modèle :

propriétaire
groupe
autres

Une ACL devient intéressante lorsque nous avons besoin d’une exception plus fine.

Par exemple :

propriétaire Alice : rw-
groupe equipe       : r--
utilisateur Bob     : r--
autres              : ---

Avec uniquement les trois classes traditionnelles, Bob devrait soit appartenir au bon groupe, soit profiter de permissions accordées plus largement.

L’ACL ajoute donc une granularité supplémentaire.

Attention : ACL et permissions classiques restent liées

Les ACL ne forment pas un système complètement indépendant des permissions traditionnelles.

Linux définit une correspondance entre certaines entrées ACL et les bits de mode du fichier. Lorsqu’une ACL possède un masque, la partie « groupe » visible dans les permissions classiques correspond notamment à ce masque plutôt qu’à la seule entrée du groupe propriétaire. Modifier les permissions avec chmod peut donc aussi modifier des éléments de l’ACL.

Cela explique pourquoi, une fois que des ACL sont présentes, il vaut mieux vérifier avec :

getfacl fichier

plutôt que de regarder uniquement :

ls -l fichier

Petit défi

Si vous possédez un second compte de test, repartez d’un fichier propre :

echo "rapport" > rapport.txt
chmod 600 rapport.txt

Vérifiez :

ls -l rapport.txt
getfacl rapport.txt

Votre mission : donner uniquement le droit de lecture au second utilisateur, sans modifier other et sans changer le propriétaire du fichier.

Ajoutez l’ACL :

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

Puis vérifiez :

getfacl rapport.txt

Posez-vous trois questions : que possède le propriétaire ? Que possède Bob ? Que possèdent les autres ?

Enfin, retirez uniquement l’accès de Bob :

setfacl -x u:bob rapport.txt

Et vérifiez une dernière fois.

Aller plus loin : les ACL par défaut

Il existe une deuxième grande famille importante : les ACL par défaut.

Elles s’appliquent aux répertoires et peuvent servir de base aux ACL des nouveaux objets créés à l’intérieur. Les fichiers ordinaires n’ont pas de default ACL.

Vous voyez probablement le lien avec notre article précédent sur umask.

Nous avions appris :

programme demande un mode
→ umask retire certains droits
→ création

Avec une ACL par défaut sur le répertoire parent, le mécanisme de création devient plus riche : l’ACL par défaut participe à la détermination des droits du nouvel objet.

Nous ne mélangeons volontairement pas les deux sujets aujourd’hui. Ce sera une excellente suite.

Sécurité

Les ACL sont particulièrement intéressantes lorsqu’elles permettent d’éviter une ouverture excessive des permissions.

Si Bob doit lire un fichier, il est préférable de raisonner sur le besoin réel plutôt que de faire :

chmod 777 document.txt

Une ACL ne rend cependant pas automatiquement une configuration sûre.

Il faut toujours vérifier :

• qui possède le fichier ;
• quelles entrées ACL existent ;
• quel masque s’applique ;
• quels droits possèdent groupe et autres ;
• si les répertoires du chemin autorisent l’accès.

Le principe reste le même : moindre privilège et vérification.

Nettoyage / rollback

Si vous avez utilisé le fichier document.txt :

setfacl -b document.txt

Cette commande retire les ACL étendues.

Vous pouvez vérifier :

getfacl document.txt

Supprimez ensuite le lab :

cd
rm -r linux-sans-magie-lab

Vérifiez simplement :

test ! -e ~/linux-sans-magie-lab && echo "Lab supprimé"

Résultat attendu :

Lab supprimé

Ce qu’il faut retenir

Les permissions Linux classiques restent notre base :

propriétaire | groupe | autres

Mais elles ne sont pas la limite du contrôle d’accès.

Une ACL permet notamment d’ajouter :

utilisateur précis → droits précis

Le trio de commandes à retenir est maintenant :

ls -l fichier
getfacl fichier
setfacl ...

ls -l donne la vue classique.

getfacl montre les règles détaillées.

setfacl permet de les modifier.

Et lorsque vous voyez un + après les permissions dans ls -l, vous savez désormais qu’il peut être utile d’aller regarder plus loin.

Linux n’a pas changé de logique. Nous avons simplement ajouté une couche supplémentaire à un modèle que vous connaissez déjà.

Références officielles

• Linux man-pages — acl(5) : https://man7.org/linux/man-pages/man5/acl.5.html
• Linux man-pages — getfacl(1) : https://man7.org/linux/man-pages/man1/getfacl.1.html
• Linux man-pages — setfacl(1) : https://man7.org/linux/man-pages/man1/setfacl.1.html

Conclusion

Les ACL prolongent naturellement ce que nous avons appris sur rwx, chmod, Permission denied et umask.

Elles ne remplacent pas les permissions classiques : elles permettent simplement d’exprimer des exceptions plus précises.

La méthode reste la même : observer, modifier le minimum nécessaire, puis vérifier le résultat réel.

---