Pas Tout A Fait

Sur un serveur de fichier par exemple, il arrive fréquemment que les limites de la gestion des droits d'Unix soit atteinte. Imaginons par exemple la situation suivante :

• Un répertoire "/var/partage/"
• Le besoin que l'utilisateur "xavier" soit le propriétaire de ce répertoire.
• Le besoin que le groupe "Devels" ai tout les droits sur ce répertoire.
• Le besoin qu'un second groupe, "Testeurs" ai les droits de lecture et exécution sur ce répertoire.
• Le besoin que les autres n'ai aucun accès à ce répertoire.

Dans un cas comme celui là, les limites des droits de base sont atteintes, une telle organisation des droits n'est pas possible. D'une façon générale, dans un environnement de travail collaboratif, une organisation via les permissions standards n'est plus envisageable. Mais comme toujours avec GNU/Linux, une solution élégante existe. Les ACL.

Voyons ça de plus près !

Rendre possible l'utilisation des ACLs

Les noyaux récents sont en général compilés avec le support des ACLs. Pour le vérifier, utilisez la commande "grep ACL /boot/config-votrenoyau". Chez moi, j'obtiens ça :

$ grep ACL /boot/config-2.6.27-10-generic
CONFIG_GENERIC_ACL=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT4DEV_FS_POSIX_ACL=y
CONFIG_FS_POSIX_ACL=y
CONFIG_JFS_POSIX_ACL=y
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_V3_ACL=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_XFS_POSIX_ACL=y

La première ligne "CONFIG_GENERIC_ACL=y" indique que les ACLs sont supportées par mon noyau. Les lignes suivantes indiquent les systèmes de fichiers utilisables avec les ACLs.

Mais le support dans le noyau ne suffit pas, il faut également indiqué lors du "mountage" des partitions que nous allons utiliser les ACLs. C'est très simple à déclarer, même sur une partition déjà montée. Il faut employer l'option "acl" :

$ sudo setfacl -m u:minimal:rwx Castlevania-SOTN-PSX-PAL.iso
        setfacl: Castlevania-SOTN-PSX-PAL.iso: Opération non supportée
$ sudo mount -o remount,acl /mnt/games/
$ sudo setfacl -m u:minimal:rwx Castlevania-SOTN-PSX-PAL.iso
$ sudo getfacl Castlevania-SOTN-PSX-PAL.iso
# file: Castlevania-SOTN-PSX-PAL.iso
# owner: mpatout
# group: mpatout
user::rwx
user:minimal:rwx
group::rwx
mask::rwx
other::r-x

Dans l'exemple ci-dessus, une première tentative pour ajouter une ALC sur le fichier "Castlevania-SymphonyoftheNight(PSX-PAL).iso" a renvoyé une erreur indiquant le non support des ACLs. Puis la partition "/mnt/games" qui contient ce fichier a été remonter à la volée avec le support des ACLs. Ensuite, plus de problème pour indiquer l'ACL.

Il est bien sur possible, et conseillé, de spécifier l'utilisation des ACLs dans le fichier /etc/fstab, toujours grâce à l'option "acl" :

# Games - /dev/sda6
UUID=AeR5GB /mnt/games ext3 relatime,acl 0 2

Ainsi, la partition supportera les ACLs dès le démarrage et à chaque montage.
Maintenant, voyons plus en profondeur comment manipuler les ACLs, à l'aide des commandes que nous venons d'utiliser dans ce petit exemple.

Manipuler les ACLs

Deux commandes permettent de lister et d'éditer les ACLs.

• getfacl : Pour visualiser les permissions actuelles.
• setfacl : Pour réaliser des modifications.

getfacl est très simple d'emploi, puisqu'il suffit d'indiquer un fichier ou répertoire en paramètre pour visualiser les droits présents sur cet élément :

$ sudo getfacl right.test 
# file: right.test
# owner: mpatout
# group: mpatout
user::rw-
user:minimal:rw-
group::r--
group:staff:r-x
mask::rwx
other::r--

On retrouve ici user,group et other, qui représente les droits classiques sous GNU/Linux. Ainsi, "getfacl" utilisé sur un fichier ne disposant pas d'ACL renvoie les mêmes informations que "ls -l", mais présentées différemment. Mais on remarque la présence des lignes "user:minimal" et "group:staff", et d'une énigmatique ligne "mask".

La ligne "user:minimal:rw-" indique que l'utilisateur "minimal" dispose des droits de lecture (r) et d'écriture (w) sur ce fichier. Par contre pas de droit d'exécution (-).

La ligne "group:staff:r-x" indique que le groupe "staff" dispose des droits de lecture (r) et d'exécution (x), mais pas de droit d'écriture (-).

La ligne "mask:rw-" est particulière. Elle correspond à la synthèse des droits les plus importants enregistrés sur le fichier. Ici "rwx", puisque l'utilisateur minimal peut lire et écrire et que le groupe staff peut lire et exécuter. Prenons un autre exemple pour illustrer le comportement du mask :

$ sudo getfacl right.test 
# file: right.test
# owner: mpatout
# group: mpatout
user::rwx
user:minimal:rw-
group::r--
group:staff:rw-
mask::rw-
other::r--

On remarque ici que les droits classiques de "user" n'influences pas le mask. Donc on retrouve une ligne "mask:rw-" malgré le droit d'exécution unique dont dispose l'utilisateur "mpatout" avec les droits classiques. Le mask permet de limité/étendre les permissions globalement, avec "m:", par exemple :

$ sudo setfacl -m m:r right.test 
$ sudo getfacl right.test 
# file: right.test
# owner: mpatout
# group: mpatout
user::rwx
user:minimal:rw-        #effective:r--
group::r--
group:staff:rw-        #effective:r--
mask::r--
other::r--

La commande "setfacl -m m:r right.test" a limité les droits à la seul lecture. C'est indiqué par le "#effective:r--".

Un fichier disposant d'une liste d'ACLs sera présenté avec un "+" en bout de ligne par la commande "ls" :

$ ls -l /var/partage
drwxrwx---+ 2 xavier devels 4096 1935-10-09 06:37 partage

Il est grand temps de s'intéresser à l'autre commande: "setfacl".

Exemples en situation

Prenons l'exemple de tout à l'heure :

• Un répertoire "/var/partage/"
• Le besoin que l'utilisateur "xavier" soit le propriétaire de ce répertoire.
• Le besoin que le groupe "devels" ai tout les droits sur ce répertoire.
• Le besoin qu'un second groupe, "testeurs" ai les droits de lecture et exécution sur ce répertoire.
• Le besoin que les autres n'ai aucun accès à ce répertoire.

Il faut dans un premier temps donner au répertoire comme propriétaire "xavier", et comme groupe "devels", ainsi que les droits "rwx" au propriétaire et au groupe, et rien aux autres. Et cela avec les permissions classiques :

$ sudo chown -R xavier.devels /var/partage
$ sudo chmod -R 770 /var/partage

Nous remplissons déjà trois conditions, qui concerne le propriétaire, le premier groupe et les autres. Mais pour donner au groupe "testeurs" les droits attendus, il faut se tourner vers setfacl, comme ceci :

$ sudo setfacl -Rm u:xavier:rwx,g:devels:rwx,g:testeurs:r-x,o:--- /var/partage/
$ sudo getfacl /var/partage/
# file: /var/partage/
# owner: xavier
# group: devels
user::rwx
user:minimal:rwx
group::rwx
group:root:rwx
group:testeurs:r-x
mask::rwx
other::---

C'est aussi simple que ça !

Cette commande donne donc tout les droits au propriétaire "xavier" (u:xavier:rwx), puis tout les droits au groupe "devels" (g:devels:rwx), ensuite les droits de lecture et exécution au groupe "testeurs" (g:testeurs:r-x), et enfin, rien aux autres (o:---) sur le répertoire /var/partage. Et cela de façon récursive sur les sous-dossiers et fichiers, par le biais de l'option -R. On remarque que l'utilisation de la virgule permet d'enchainer les utilisateurs, ou ici, les groupes.

La syntaxe de "setfacl" est vraiment très abordables et claires, et la puissance de cette commande est énorme. C'est l'occasion de voir quelques détails très utiles.

Pour allez plus loin

setfacl pour remplacer chmod

La commande "setfacl" permet de modifier les droits standards, en remplacement "chmod". Pour cela, il suffit de ne pas spécifier d'utilisateur ou de groupe, de cette façon :

sudo setfacl -m u::rwx,g::r-x:o::---

Ici, le propriétaire obtient tout les droits, le groupe les droits de lecture et écriture, et rien pour les autres. Notez que les éventuelles droits antérieurs sont supprimés par cette commande, tout comme avec "chmod". Ainsi, notre fichier ayant pour droits "r-x-w-r-x" en format standard prendra les droits "rwx-r-x---" si on lui passe la commande ci-dessus.

Héritage des droits étendus

Comme vu précédemment, l'utilisation de "setfacl -Rm" modifie récursivement le contenu d'un répertoire. Par contre, par défaut un fichier nouvellement créer aura les droits définis par le "umask" dont dispose son répertoire parent. On peut modifier ce comportement en ajoutant aux répertoires, et uniquement à ceux ci, un attribut "default".
Ainsi, tout fichiers ou répertoires crées par la suite disposera par héritage des droits du dossier parent. Par exemple :

$ sudo setfacl -m d:u:xavier:rwx /var/partage
$ sudo getfacl /var/partage
getfacl: Removing leading '/' from absolute path names
# file: var/partage/
# owner: xavier
# group: devels
user::rwx
user:xavier:rwx
group::rwx
group:devels:rwx
group:testeurs:r-x
mask::rwx
other::---
default:user::rwx
default:user:xavier:rwx
default:group::rwx
default:mask::rwx
default:other::---

Supprimer les ACLs

Pour totalement supprimer les ACLs d'un fichiers, la commande suivante fait le grand ménage :

$ sudo setfacl -b /var/partage

Pour faire dans la finesse, l'option -x permet de spécifier un ou des utilisateur-s/groupe-s, de cette manière :

$ sudo setfacl -x u:xavier,g:testeurs /var/partage

Ici, tout les droits ACLs définis pour l'utilisateur "xavier" et le groupe "testeurs" sont éradiqués.

La préservation des ACLs

Lors de la copie d'un fichier avec "cp", il faut explicitement indiquer que l'on souhaite conserver les permissions en place, en utilisant l'option "-a". Le déplacement avec "mv" conserve lui automatiquement les permissions des fichiers.
En cas d'impossibilité de conservation des droits, la copie/déplacement retourne un message indiquant l'erreur :

$ sudo cp -a /var/partage/main.c /un/repertoire/sans/support/des/ACLs/
   cp: preserving permissions for `/un/repertoire/sans/support/des/ACLs/main.c': Opération non supportée