LinuxPedia

Wiki libre et indépendant dédié à GNU-Linux et BSD.

Outils pour utilisateurs

Outils du site


expert:acl_posix

Comment fonctionnent les ACL Posix ?

Comment fonctionnent les ACL Posix sous Linux…

Problématique

La mise en oeuvre de droits sur les fichiers d’un système linux peut parfois manquer de souplesse. Comme vous le savez, un fichier peut se voir affecter des droits pour trois types d’utilisateur différents : le propriétaire, le groupe propriétaire et « le reste du monde ».

Imaginons un instant un fichier exemple.txt. L’utilisateur titi (propriétaire du fichier) peut le lire et le modifier. Les utilisateurs du groupe propriétaire peuvent juste le consulter. Le « reste du monde » ne le voit même pas….

Qu’advient-il de l’utilisateur toto qui n’est ni propriétaire, ni membre du groupe propriétaire et pour qui on souhaite donner des droits en écriture sur le dit fichier (même droit que l’utilisateur titi) ? De fait, l’absence de gestion de droits atomiques (droits utilisés sur les fichiers Windows de type NTFS depuis plusieurs années) est un grief qui a souvent été reproché aux systèmes Linux.

Solution

Aujourd’hui, cela n’a plus lieu d’être puisque la mise en oeuvre de tels droits est désormais possible grâce à l’utilisation des ACL (Listes de Contrôle d'Accès). La mise en oeuvre de ces listes est conforme à la norme POSIX (Portable Operating System Interface).

Mise à jour noyau

Le noyau doit impérativement être compilé avec les options qui vont bien :

  • Les noyaux 2.4.x (ext2, ext3, nfs) et 2.6.x (nfs) doivent systématiquement être patchés.
  • Les noyaux 2.6 incluent d’origine le support des ACL pour ext2, ext3, jfs et xfs…
  • Les patchs sont disponibles depuis l’adresse : http://acl.bestbits.at/download.htm

Vous devez donc vérifier que le noyau de votre distribution est compilé avec les options idoines… Sinon, vous avez gagné le droit de rejouer et de recompiler le noyau avec ces mêmes options activées !

Pour vérifier :

$ cat /boot/config* | grep _ACL

Doit au moins renvoyer les lignes suivantes (pour un système de fichiers de type ext3) :

  • CONFIG_EXT3_FS_POSIX_ACL=y
  • CONFIG_JFS_POSIX_ACL=y
  • CONFIG_FS_POSIX_ACL=y

Naturellement, vous adapterez en fonction du type de système de fichiers utilisé.

Mise à jour paquetages

On installe les paquets nécessaires à la gestion des ACL Sous Mandrake 10 par exemple (et à l’heure où j’écris ces lignes) :

# urpmi acl-2.2.22-1mdk.i586 libacl1-2.2.22-1mdk.i586

Sous Debian/woody, un

# apt-get install acl

Sous openSUSE :

#zypper in acl

Suffira, l’installation des dépendances libacl1, libattr1, et libc6 se faisant automatiquement si besoin… Dans tous les cas, les paquets acl-x.x.x et libacl1-x.x.x doivent être installés.

Prise en compte de ACL’s

Pour activer la prise en charge des ACL par le système de fichiers, et ce, pour chaque partition souhaitée, il faudra exécuter deux actions distinctes. Dans l’exemple qui suit, on ne souhaite activer les ACL que sur /dev/hda1… Si on avait voulu les activer sur plus d’une partition, on aurait renouvelé ces actions autant de fois que de partitions à activer.

1. Pour activer les ACL sur /dev/hda1 sans avoir à redémarrer le système, on exécute la commande :

# mount -o remount,acl /dev/hda1

2. Pour automatiser l’activation des ACL lors des prochains reboot, il faudra modifier le fichier /etc/fstab en ajoutant acl aux options à transmettre au montage. Par exemple la ligne :

/dev/hda1 / ext3 errors=remount-ro 0 1

Deviendrait :

/dev/hda1 / ext3 acl,errors=remount-ro 0 1

Vérification

Tout est désormais en place, et les ACL devraient être utilisables sur /dev/hda1. On va le vérifier.

$ mkdir /home/loick/ACL
$ cd /home/loick/ACL
$ touch test.acl
$ ls -l test.acl
-rw-rw-r-- 1 loick:loick 80 jun 20 15:24 test.acl

Le fichier test.acl est donc bien en lecture/écriture pour le user et le groupe loick, et en lecture seule pour le reste du monde. La commande « getfacl » va nous permettre de voir les ACL appliquées à ce fichier (qui seront celles correspondant aux droits unix du fichier par défaut puisque nous venons juste de le créer).

$ getfacl test.acl
# file : test.acl
# owner : loick
# group : loick
user ::rw-
group ::r--
other ::r--

Pour vérifier que la modification des ACL fonctionne, on va autoriser l’utilisateur cecile à écrire dans le fichier test.acl :

$ setfacl -m u:cecile:w test.acl

Vérifions que la modification a bien été prise en compte…

$ getfacl test.acl
# file : test.acl
# owner : loick
# group : loick
user ::rw-
user :cecile :-w-
group ::r--
mask ::rw-
other ::r--

On voit bien que désormais l’utilisateur cecile a des droits en lecture et en écriture sur le fichier test.acl.

À noter : Sur une distribution SuSE (9.1), vous vous apercevrez de la présence d’une ACL sur un fichier par la présence du signe + dans la sortie renvoyée par la commande ls :

$ ls -l test.acl
-rw-rw-r--+ 1 loick loick 80 jun 20 15:24 test.acl

Sur une distribution Mandrake ou Debian, la commande suivante ne permet plus de distinguer les droits réels appliqués au fichier test.acl :

$ ls -l test.acl
-rw-rw-r-- 1 loick loick 80 jun 20 15:24 test.acl

Le fichier est pourtant bien modifiable puisque si on fait un : $ su -c ’vi test.acl’ cecile (ouverture par l’utilisateur cecile du fichier test.acl pour modification), on peut enregistrer le fichier sans problème après l’avoir modifié !

Pour visualiser la présence d’ACL sur le fichier test.acl, il faut patcher le paquetage coreutils (par exemple, pour SuSE : http://acl.bestbits.at/download.htm… ).

Utilisation

Quelques définitions Trois notions principales sont à appréhender :

  1. ACL « minimale » : Composée exclusivement d’éléments de type propriétaire, groupe et « reste du monde », l’ACL minimale est une traduction « en ACL » des droits d’accès traditionnels Unix.
  2. ACL étendue : L’ACL étendue prolonge les droits de l’ACL minimale. Elle contient au moins un élément de type mask et peut contenir des éléments de type utilisateur et/ou groupe.
  3. ACL par défaut : Les ACL par défaut ne peuvent être appliquées qu’aux répertoires et définissent de quels droits un objet du système de fichiers devra hériter (de son répertoire parent) lors de sa création.

Mise en oeuvre élémentaire

Création

La création d’une ACL n’a pas de raison d’être. Une partition montée correctement avec l’option ACL affichera automatiquement l’ ACL minimale d’un fichier lors de l’interrogation à l’aide de la commande : $ getfacl nom.fichier

Ajout/Modification des droits utilisateur/groupe

Pour modifier/ajouter l’ACL d’un fichier, on utilise la commande setfacl et l’option -m (pour modify).

Pour modifier l’ACL d’un fichier/dossier, il faut, soit être propriétaire du fichier (utilisateur ou groupe), soit être super-utilisateur (root).

  • Pour modifier les droits d’un utilisateur, on utilisera le paramètre u, suivi du nom ou de l’uid 1) de l’utilisateur, suivi des droits à affecter en respectant le format u[ser] :]uid [ :perms]. Si l’uid est vide, le propriétaire sera utilisé. Pour permettre à l’utilisateur cecile d’écrire dans un fichier appartenant à l’utilisateur loick (fichier pour lequel elle n’a normalement que des droits en lecture seule) on utilisera la commande :
$ setfacl -m u:cecile:w test.acl (-m pour modifier, u pour user et w pour écriture).
  • Pour modifier les droits d’un groupe, on utilisera le paramètre g, suivi du nom ou du gid 2) du groupe, suivi des droits à affecter en respectant le format g[roup] :gid [ :perms]. Si le gid est vide, le groupe propriétaire sera utilisé. Pour permettre au groupe admin d’écrire dans un fichier appartenant à l’utilisateur loick (fichier pour lequel les membres du groupe admin n’ont normalement que des droits en lecture seule) on utilisera la commande :
$ setfacl -m g:admin:w test.acl (-m pour modifier, u pour user et w pour écriture).
  • Pour modifier les droits du reste du monde (other), on utilisera le paramètre o, suivi des droits à affecter en respectant le format o[ther][ :] [ :perms]

Suppression d’une ACL

Lorsqu’on souhaite supprimer une ACL, on ne peut, en fait, que supprimer les éléments de type mask et/ou utilisateur/groupe. Le maximum des entrés de l’ACL supprimées, il restera quand même (et c’est on ne peut plus logique) les entrées correspondantes aux droits unix du fichier concerné.

  • Pour détruire toutes les entrées d’une ACL étendue :
$ setfacl -b mon.fichier
  • Pour détruire certains types particuliers d’entrées (les permissions ne doivent pas être passées en paramètre) :
$ setfacl -x g:users mon.fichier

Dans l’exemple ci-dessus, on enlève de l’ACL toutes les entrées correspondantes au groupe users.

ACL par défaut

Une ACL par défaut s’applique à un répertoire. Ce type d’ACL permet de définir un certain nombre de paramètres qui seront appliqués automatiquement et par défaut à tout fichier ou répertoire créé sous le répertoire de départ.

Vous suivez ?

Super, on continue !

L’ intérêt consiste en la mise en oeuvre de procédures globales de gestion des droits ACL au sein d’une arborescence donnée. De cette façon, et en appliquant l’ACL par défaut souhaitée sur le répertoire /home/loick/partage, je peux décider que cecile pourra écrire dans tous les fichiers/répertoires créés dans ce même répertoire et ce, sans action supplémentaire de ma part, et quelque soit l’utilisateur qui aura créé les fichiers.

Les droits seront hérités automatiquement. Cool, non ?

Création d’une ACL par défaut

Soit le répertoire mon.repertoire (drwxr-xr-x loick users). On décide qu’à partir de maintenant, cecile pourra lire et écrire dans les fichiers/répertoires créés sous mon.repertoire. On crée donc l’ACL par défaut :

$ setfacl -m d:u:cecile:rw mon.repertoire

On vérifie :

$ getfacl mon.repertoire
# file: mon.repertoire
# owner: loick
# group: users
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:cecile:rw-
default:group::r-x
default:mask::rwx
default:other::r-x

Suppression d’une ACL par défaut

$ setfacl -k mon.repertoire

Naturellement, pour plus de détail sur ces fonctions et leur récursivité, je vous invite à consulter les pages man (setfacl(1)) et en particulier l’option -R.

Et les masques dans tout ça ?

En fait, la magie de la gestion des ACLs réside dans l’utilisation du paramètre masque. C’est en jouant avec celui-ci que les ACLs gardent une cohérence avec les droits unix.

Le masque s’ajuste automatiquement aux modifications des entrées ACL… Une fois de plus, un petit exemple sera plus clair qu’un long discours.

  • Créons un fichier quelconque (droit = droit par défaut du système soit 644) :
$ touch monfichier

Les droits appliqués au fichier sont :

$ ls -l monfichier
-rw-r--r-- 1 loick users 0 2004-07-06 16:06 monfichier

Vérifions l’ACL minimale qui a été générée automatiquement :

$ getfacl monfichier
# file: monfichier
# owner: loick
# group: users
user::rw-
group::r--
other::r--

On notera l’absence de l’élément « mask »

  • Modifions cette ACL pour ajouter des droits en lecture, écriture et exécution à l’utilisateur cecile et au groupe cecile :
$ setfacl -m user:cecile:rwx,group:cecile:rwx monfichier

Les droits appliqués au fichier sont désormais :

$ ls -l monfichier
-rw-rwxr--+ 1 loick users 0 2004-07-06 16:06 monfichier

Au passage, on aura noté le signe + qui prouve qu’une ACL étendue a bien été appliquée à ce fichier).

Vérifions la bonne modification de l’ACL :

$ getfacl monfichier
# file: monfichier
# owner: loick
# group: users
user::rw-
user:cecile:rwx
group::r--
group:cecile:rwx
mask::rwx
other::r--

Apparaît désormais l’élément mask avec les attributs rwx (qui correspondent aux droits les plus tolérants pouvant être pris par le groupe). On constate ainsi que l’attribut mask, automatiquement généré, permet de visualiser un fichier (possédant les droits réels rw-r–r–) comme possédant les droits -rw-rwx-r– (sortie de la commande ls).

Persistance des ACLs lors des manipulations de fichiers

Malgré l’intégration des ACL par le système, leur gestion peut être mal ou pas prise en compte par certaines applications. On distingue deux groupes d’applications différents.

Applications de sauvegarde

Les applications de sauvegarde, à l’exception de star, ne savent pas garantir la prise en compte complète des ACL. star est certainement disponible en paquetage binaire pour votre distribution préférée, sinon, vous pouvez trouver la dernière version sur http://freshmeat.net/projects/star.

Pour pallier ce problème, on peut tout à fait récupérer les ACL avant la sauvegarde et les restituer sur la restauration (récupération avec getfacl -R et restauration avec setfacl).

J’ai quand même rencontré des problèmes en utilisant cette méthode du fait du stockage des règles en relatif (retrait du /) dans le fichier texte. Je vous conseillerai donc d’installer et d’utiliser star. Applications de manipulations de fichier.

Si les paquetages sont correctement mis à jour (coreutils entre autres), les commandes classiques (cp, mv, ls) prennent en compte les ACL. Pour les éditeurs et les gestionnaires de fichiers moins conventionnels, cela dépend du principe de fonctionnement de l’application. Si les modifications sont apportées dans le fichier d’origine, l’ACL est conservée, dans le cas contraire il y a toutes les chances que les ACL soient perdues…

Côté performance

Encore une fois l’excellent travail réalisé par A. Grünbacher permet d’appréhender l’impact des ACL sur la rapidité d’accès aux systèmes de fichiers et ce en fonction de la plupart des types de système de fichiers. Il ressort de son étude que, sur un type de fichier ext2/ext3 et de façon très générale, la mise en oeuvre des ACL n’augmente que de très peu les temps d’accès aux fichiers et ne sera que peu perceptible par l’utilisateur. En revanche, l’utilisation des ACL avec le système de fichiers XFS (surtout 256) semble pénalisante.

Si ce sujet vous intéresse, n’hésitez pas à consulter sa synthése 3))

Mémento des commandes utiles

  • Ajouter les droits de lecture à un utilisateur spécifique :

setfacl -m u:lisa:r test.acl

  • Ajouter les droits de lecture à un utilisateur spécifique pour tous les répertoires et fichiers inclus dans le répertoire DIR (récursivement) :

setfacl -R -m u:lisa:r DIR

  • Enlever les droits en écriture à tous les groupes et tous les utilisateurs (en utilisant les droits de masque) : setfacl -m m::rx test.acl
  • Enlever l’ensemble des ACL du groupe staff pour le fichier test.acl : setfacl -x g:staff file
  • Appliquer les ACL du fichier test.acl au fichier test2.acl : getfacl file1 | setfacl –set-file=- test2.acl
  • Définir des ACL par défaut pour le répertoire DIR (tous les fichiers créés dans le répertoire auront ces ACL positionnées par défaut) : setfacl -m d:u:cecile:rw DIR
  • Définir les ACL courantes comme ACL par défaut : getfacl – access dir | setfacl -d -M- dir
  • Enlever toutes les ACL positionnées sur un fichier donné : setfacl -b test.acl

Conclusion

Comme vous avez pu le constater lors de cette rapide présentation, la mise en oeuvre des ACL sur un système linux est désormais possible et pour certaines distributions, nativement gérée.

Les ACL étendent les possibilités de gestion des droits d’accès de façon très significative et ce sans alourdir outre mesure le système existant. Cela ouvre des perspectives considérables en particulier par l’interfaçage avec samba. Dans ce cadre, la gestion des ACL permet à des serveurs linux de remplacer des serveurs windows tout en offrant aux clients windows une maîtrise équivalente sur la gestion des droits appliqués aux fichiers du serveur…

Enfin, pour tous ceux qui souhaitent aller plus loin je vous conseille l’excellentissime papier d’A. Grünbacher « POSIX Access Control Lists on Linux »[GRUN01].

Pour finir, j’aimerai remercier JC STIEGLER pour l’aide apportée lors de la relecture et de la correction de ce document…

Bibliographie 1 : Grünbacher, Andreas, POSIX Access Control Lists on Linux, 2003

date maj : 9 août 2004

1)
User IDentifier. Nombre permettant d’identifier un utilisateur dans un système multiutilisateur, par exemple pour lui associer ses processus.
2)
Group IDentifier. Nombre permettant d’identifier un groupe dans un système multiutilisateur.
3)
Chapitre 10 « EA and ACL Performance » (cf. note 1
expert/acl_posix.txt · Dernière modification : 2018/11/17 12:53 de 127.0.0.1