expert:acl_posix
no way to compare when less than two revisions
Différences
Ci-dessous, les différences entre deux révisions de la page.
— | expert:acl_posix [2018/11/17 12:53] (Version actuelle) – créée - modification externe 127.0.0.1 | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | ====== 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, | ||
+ | |||
+ | 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, | ||
+ | |||
+ | ===== Solution ===== | ||
+ | Aujourd’hui, | ||
+ | |||
+ | |||
+ | |||
+ | ===== 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:// | ||
+ | |||
+ | 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 / | ||
+ | |||
+ | 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, | ||
+ | |||
+ | ===== 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/ | ||
+ | |||
+ | # 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 / | ||
+ | |||
+ | 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 : | ||
+ | |||
+ | / | ||
+ | |||
+ | ===== Vérification ===== | ||
+ | Tout est désormais en place, et les ACL devraient être utilisables sur /dev/hda1. On va le vérifier. | ||
+ | |||
+ | $ mkdir / | ||
+ | $ cd / | ||
+ | $ 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/ | ||
+ | |||
+ | $ 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), | ||
+ | |||
+ | Pour visualiser la présence d’ACL sur le fichier test.acl, il faut patcher le paquetage coreutils (par exemple, pour SuSE : http:// | ||
+ | |||
+ | ===== Utilisation ===== | ||
+ | Quelques définitions Trois notions principales sont à appréhender : | ||
+ | - ACL « minimale » : Composée exclusivement d’éléments de type propriétaire, | ||
+ | - 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. | ||
+ | - 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/ | ||
+ | Pour modifier/ | ||
+ | |||
+ | Pour modifier l’ACL d’un fichier/ | ||
+ | |||
+ | * Pour modifier les droits d’un utilisateur, | ||
+ | |||
+ | $ 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 ((Group IDentifier. Nombre permettant d’identifier un groupe dans un système multiutilisateur.)) 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/ | ||
+ | |||
+ | * 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 / | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | $ setfacl -m d: | ||
+ | |||
+ | On vérifie : | ||
+ | |||
+ | $ getfacl mon.repertoire | ||
+ | # file: mon.repertoire | ||
+ | # owner: loick | ||
+ | # group: users | ||
+ | user::rwx | ||
+ | group::r-x | ||
+ | other::r-x | ||
+ | default: | ||
+ | default: | ||
+ | default: | ||
+ | default: | ||
+ | default: | ||
+ | |||
+ | ===== Suppression d’une ACL par défaut ===== | ||
+ | $ setfacl -k mon.repertoire | ||
+ | |||
+ | Naturellement, | ||
+ | |||
+ | 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: | ||
+ | |||
+ | 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: | ||
+ | group::r-- | ||
+ | group: | ||
+ | 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, | ||
+ | |||
+ | 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, | ||
+ | |||
+ | ===== 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 ((Chapitre 10 « EA and ACL Performance » (cf. note 1))) | ||
+ | |||
+ | ===== 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: | ||
+ | * 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, | ||
+ | |||
+ | 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, | ||
+ | |||
+ | date maj : 9 août 2004 |
expert/acl_posix.txt · Dernière modification : 2018/11/17 12:53 de 127.0.0.1