Les Access Control List : Gestion avancée des droits sous linux

Par défaut, la gestion des droits sous Linux est relativement basique (bien que souvent suffisante). En effet, il n'est possible de permettre ou d'interdire la lecture, l'écriture et l'exécution de fichiers que pour trois catégories d'utilisateurs : le propriétaire du fichier, le groupe auquel appartient le propriétaire et le reste du monde. Cette gestion des droits permet de configurer les accès aux fichiers dans la plupart des situations simples mais peut s'avérer limitée, par exemple, dans un contexte où plusieurs utilisateurs doivent accéder à une ressource partagée alors qu'ils n'ont pas de groupe commun.

Les ACL voudraient permettre de pallier ce manque grâce à une gestion avancée des droits. Ainsi, il deviendrait possible d'autoriser un utilisateur tiers à effectuer des opérations sur un fichier (dossier) sans autoriser tout un groupe ou tout le reste du monde. Voir les exemples pour plus d'informations.
Mise en garde : Cependant, fin 2014, ce scénario passe sous silence une limitation majeure: il ne fonctionne que pour la création ex-nihilo de fichiers ou de dossiers. En effet, les commandes cp (copie) et mv (déplacement), ainsi que leurs mises en œuvre dans les outils graphiques de gestion des fichiers (p.e. nautilus, sans parler de rsync, rcp, scp…) ne se plient pas à la présence d'une acl par défaut (c-à d définie sur le dossier cible de la copie ou du déplacement). Ainsi, pour permettre aux acl de "marcher" de façon (presque) transparente, il fau(drai)t que tous les utilisateurs des partages (en particulier ceux dont on voudrait qu'ils n'aient que le droit de lecture) disposassent des droits complets sur les dits partages, possédassent la compréhension du mécanisme des acl, de la maîtrise de la ligne de commande (ou de l'interface graphique eiciel)… et de la confiance de tous les autres pairs partageurs en ce qui concerne le droit d'écriture (modification/création/suppression): ceci afin qu'ils aient le droit de réappliquer l'acl par défaut du dossier cible sur les objets copiés/déplacés dans celui-ci… sans être obligés de faire appel à un utilisateur disposant lui-même du droit d'écriture après chaque déplacement/copie. Cette limitation restreint de façon drastique la portée des acl à un très petit nombre d'usages, excluant par là même de la notion de partage le cas d'un usage familial/pme/tpe dans lequel certains pourraient écrire, d'autres seulement lire, et d'autre encore n'ayant aucun accès. Il existerait un mécanisme à base de l'API système "inotify" qui ~permettrait~ de généraliser le fonctionnement des acl quand elles resteraient la seule solution, mais aucun développeur de distribution système GNU ne s'est jamais aventuré à intégrer ceci officiellement dans sa propre distribution grand public. Pour le scripteur du dimanche, voir l'aide des commandes shell inotifywait et inotifywatch : apt://inotify-tools
Une autre solution, plus brutale et hideuse, à la portée de l'administrateur moyen, consisterait à établir un script déclenché par une tâche planifiée chaque minute (hideuse), script qui réappliquerait de façon récursive sur toute une arborescence (brutale car on pourrait souhaiter des spécificités/casse l'héritage pour tel ou tel sous-répertoire ou fichier) l'acl par défaut et l'acl d'accès définies au niveau du dossier parent de la dite arborescence

sudo chown U:G arbre
sudo chmod +R g=rwXs arbre
sudo setfacl -R --set d:u::...,d:u:u2:...,d:u:un:...,d:g::...,d:g:g2:...,d:g:gn:...,d:o::...,d:m::...,u::...,u:u2:...,u:un:...,g::...,g:g2:...,g:gn:...,o::...,m::... arbre''

Une autre piste, formellement déconseillée sur le site officiel d'Ubuntu (indépendamment des acl), serait une modification du umask, mais sa valeur par défaut (0002 dans Ubuntu) n'explique pas l'amputation de l'héritage de l'acl [par défaut] lors des copies/déplacements. (observer, par exemple et hors de toute modification du umask, qu'un dossier, copié vers un dossier disposant lui-même d'une acl par défaut et donc d'un masque par défaut, perd le masque par défaut du parent alors qu'il devrait en hériter)
Le seul OS grand public sachant gérer nativement les acl aujourd'hui et depuis 1990 s'appelle W…(NT et ses descendants).

Les ACL ne sont nativement pas activées sur Ubuntu mais le noyau les prend en charge. Le paquet apt://acl doit normalement être déjà installé.

La commande

grep ACL /boot/config-$(uname -r)

permet de vérifier si le noyau prend en charge les ACL. Elle doit retourner 'y' pour le type système de fichier qui nous intéresse.

Il faut maintenant préciser lors du montage de la partition que l'on veut utiliser les ACL. Si la partition concernée par le partage est de type ext4, la suite est inutile (voir la note à la fin de cette section).

Soit en montant la partition avec l'option acl

mount -t ext3 -o defaults,acl /dev/sdaX/ /mount/folder/

soit en inscrivant l'option dans le fichier fstab

UUID=xxxxxxxxx /               ext4    [autres options],acl 0       1

puis en remontant la partition (si l'on ne veut pas redémarrer)

mount -a -o remount /dev/sdax

(note) : si la partition concernée par le partage est de type ext4 le support des acl est actif par défaut: l'option de montage "acl" a été remplacée par "noacl", qui devient donc celle à utiliser si on veut… désactiver le support des acl.

l'attribution des droits se fait grâce à la commande setfacl, la lecture des droits avec getfacl

Ainsi les deux commandes suivantes sont équivalentes :

chmod u=rw fichier

setfacl -m u::rw fichier

Un fichier dont les ACL auront été spécifiés verra s'ajouter un + à la fin de la liste des droits avec la commande :

ls -l fichier

getfacl permet d'afficher l'ensemble des permissions définies :

$ getfacl fichier
# file: fichier
# owner: utilisateur
# group: utilisateur
user::rwx
user:utilisateur1:rw-
user:utilisateur2:r--
group::r--
mask::rwx
other::---

ici on peut voir que le propriétaire du fichier (utilisateur) a les droits rwx, utilisateur1 rw- et utilisateur2 r–, les autres utilisateurs n'ont aucun droit

getfacl –omit-header … supprime de l'affichage les 3 premières lignes du nom de fichier, owner et group.

$ mkdir dir
$ ls -ld dir
drwxr-xr-x 2 root root 4096 Mar 12 13:54 dir
$ getfacl --omit-header dir
user::rwx
group::r-x
other::r-x

Sans acl, la command getfacl donne les mêmes informations que ls -ld

getfacl -d … spécifie des acl par défaut, qui ne peuvent s'appliquer qu'aux dossiers.

$ setfacl -m user:fdsadmin:rwx dir
$ setfacl -d -m group:nasgrp:r-x dir
$ getfacl --omit-header dir
user::rwx
user:fdsadmin:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:nasgrp:r-x
default:mask::r-x
default:other::r-x

getfacl –access –default … L'affichage précédent peut se décomposer en droits d'accès fichier, et en droits par défaut :

$ getfacl --omit-header --access dir
user::rwx
user:fdsadmin:rwx
group::r-x
mask::rwx
other::r-x

$ getfacl --omit-header --default dir
user::rwx
group::r-x
group:nasgrp:r-x
mask::r-x
other::r-x

Les permissions effectives sont affichées individuellement pour les users ou groups qui subissent un droit de hiérarchie supérieure différent :

$ chmod g-w dir
$ ls -ld dir
drwxr-xr-x+ 2 root root 4096 Mar 12 13:54 dir
$ getfacl --omit-header dir
user::rwx
user:fdsadmin:rwx               #effective:r-x
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:nasgrp:r-x
default:mask::r-x
default:other::r-x

Ici l'utilisateur fdsadmin qui avait pourtant les droits rwx s'est vu amputer du droit w supprimé au groupe.

Une fois compris les concepts des ACL, il est possible de gérer les changements de droits en graphique grâce au paquet apt://eiciel.

setfacl -m user:utilisateur:rw fichier

setfacl -m u:utilisateur:rw fichier

La même commande est disponible pour les groupes. Il suffit de remplacer u/user par g ou group

setfacl -m user:utilisateur:rwx,user:utilisateur2:r,group:groupe:rw fichier

setfacl -m d:u:utilisateur:r dossier

setfacl -b fichier

Contributeur : nesthib bybeu