Les ACL c’est puissant, mais faut faire gaffe

closeCet article a été publié il y a 6 ans 9 mois 8 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Le problème quand on passe d’un serveur avec PHP en module Apache à un PHP en mode FPM multi-utilisateurs, c’est que certaines habitudes et certains process partent du principe que c’est openbar sur les permissions et droits d’accès (tout appartient au même utilisateur). Pour contourner cette limitation tout en gardant un niveau de sécurité acceptable, on peut utiliser les ACL plutôt que de jouer avec les groupes, qui seront moins souples par la suite.

ACL, kézaco ?

Access Control List, permet de gérer les droits utilisateur par utilisateur et groupe par groupe sous la forme d’une liste en plus des simples permissions classiques des systèmes sous Linux avec rwx pour le propriétaire, le groupe, et le monde. C’est très puissant, et ça permet de contourner le problème que j’ai évoqué au dessus.

Le principe d’une liste de contrôle d’accès est utilisé dans plusieurs logiciels, et pas seulement pour les fichiers et dossiers sous Linux. Le logiciel de discussion vocale Mumble utilise notamment les ACL pour gérer les droits des utilisateurs sur les canaux de discussion et les fonctions du service. C’est d’ailleurs mon premier contact avec le concept d’ACL, et j’ai mis un certain temps à comprendre comment ils l’avaient implémenté.

Mais revenons au sujet d’aujourd’hui. Et commençons par le début, à savoir à quoi ressemble les permissions (extrait) :

J’ai pris un fichier et un dossier pour bien distinguer les deux, mais le principe est similaire dans les deux cas. Les deux appartiennent à l’utilisateur web1, au groupe client0, les permissions indiquent que seul le propriétaire peut modifier les deux (pour le dossier ça veut dire y ajouter des fichiers ou sous-dossiers), le groupe et le reste du monde peuvent lire (fichier) et parcourir (dossier).

Admettons maintenant que je veuille autoriser un utilisateur web13 à accéder au dossier, mais qu’il ne fait pas partie du groupe client0. Soit je l’ajoute au groupe, et si je veux lui donner des droits d’écriture (c’est ce qui est le plus bloquant généralement), je dois ajouter les droits d’écriture pour tout le groupe (pas évident si on ne veut pas que les autres membres du groupe modifient), soit on passe par des ACL.

Est-ce que le support est activé ?

En effet, comme ce n’est qu’une option du système de fichiers, il faut vérifier que c’est activé. Deux possibilités pour vérifier, la présence de l’option dans le fichier /etc/fstab, soit les infos retournées par tune2fs :

Dans mon cas, c’est dans les options du système de fichiers, si vous voulez passer par là pour l’activer, c’est la commande suivante qu’il faut taper :

En fonction des méthodes il faudra peut-être redémarrer si un remount ne suffit pas.

Les choses sérieuses

Bon, alors, comment ça fonctionne ? Commençons déjà par vérifier s’il y a quelque chose de défini :

Bon là, on a juste les permissions standards qu’on connaît déjà. Eh bien les ACL vont nous permettre de définir des permissions analogues juste pour notre utilisateur supplémentaire. Ajoutons donc les droits de lecture et surtout d’écriture sur le fichier :

J’ai fait exprès de basculer sur l’utilisateur web1 pour montrer qu’il n’est pas nécessaire d’être administrateur pour pouvoir procéder, seulement être le propriétaire du fichier. J’ai donc modifié les ACL (-m), indiqué qu’on ajouterait des permissions pour l’utilisateur web13 (u:web13), et indiqué les permissions lecture/écriture (rw). Voilà, c’est aussi simple que ça.

Il faut savoir qu’on peut, avec l’option -R, faire de même de manière récursive quand on procède sur un répertoire. Quand vous avez des milliers de fichiers à traiter d’un coup, c’est bien mieux. Vous pouvez également définir des permissions pour un groupe au lieu d’un utilisateur.

Les pièges de l’ACL

C’est bien, mais si on a besoin que les droits s’appliquent sur des fichiers et dossiers qui n’existent pas encore ? Eh oui, setfacl ne travaille par défaut que sur des fichiers ou dossiers existants. Si on veut que ça soit le cas pour les fichiers futurs, il faut placer une ACL « par défaut » sur le dossier dans lequel on veut que les fichiers héritent des permissions. L’option -d permet de s’en sortir :

Et donc tout le contenu qui sera ajouté au dossier wp-includes héritera automatiquement des droits supplémentaires. L’option récursive fonctionne aussi dans le cas présent.

Maintenant, comment savoir si des ACL sont présentes ? Ce n’est pas évident :

En effet, le seul indice permettant de savoir si des ACL sont présentes est un simple « + » à côté des permissions classiques. Pas nécessairement choquants pour un novice, un peu à l’instar du Sticky bit. C’est pour ça que j’évite de les utiliser autant que possible et invite plutôt les clients à revoir leurs processus quand c’est possible. En fonction des situations, sudo sera un outil bien plus utile pour changer d’identité en fonction des besoins (billet dans lequel j’indique pourquoi j’évite les ACL autant que possible, mais entre temps, j’ai appris à leur sujet).

Bref, je reste encore mesuré quant à leur utilisation dans un contexte où une multitude d’administrateurs n’ont pas nécessairement le réflexe de vérifier la présence de ces ACL avant de faire joujou avec les permissions, mais je suis bien moins frileux à envisager leur utilisation quand la solution ne peut pas venir d’une évolution des processus de traitement.

PS : à noter que ces ACL ne sont pas conservées dans le cadre d’outils d’archivage, de git, et probablement d’autres.

2 Commentaires
Le plus ancien
Le plus récent
Commentaires en ligne
Afficher tous les commentaires
jidea
jidea
20/06/2017 21:05

Petite erreur. le sACL sont prises en compte par pas mal d’outils d’archivage dont le plus connu tar.
https://man.cx/tar(1)/fr