Figure 35.1, « ACL minimale : éléments d'ACL comparés aux bits de droits d'accès » et la figure Figure 35.2, « ACL étendue : éléments d'ACL comparés aux bits de droits d'accès » illustrent les deux cas d'une ACL minimale et d'une ACL étendue. Les figures sont structurées en trois blocs—le bloc de gauche présente les spécifications de type des éléments d'ACL, celui du milieu un exemple d'ACL et celui de droite les bits de droits d'accès respectifs conformément au principe conventionnel de droits d'accès, par exemple, comme ls -l le montre également. Dans les deux cas, les droits d'accès owner class sont mis en correspondance avec l'élément d'ACL owner. Les droits d'accès other class sont mis en correspondance avec l'élément d'ACL respectif. Cependant, la mise en correspondance des droits d'accès group class est différent dans les deux cas.

Figure 35.1. ACL minimale : éléments d'ACL comparés aux bits de droits d'accès

Dans le cas d'une ACL minimale — sans élément mask — les droits d'accès group class sont mis en correspondance avec l'élément d'ACL owning group. Ce comportement est illustré dans Figure 35.1, « ACL minimale : éléments d'ACL comparés aux bits de droits d'accès ». Dans le cas d'une ACL étendue — avec mask — les droits d'accès group class sont mis en correspondance avec l'élément mask. Ce comportement est illustré dans Figure 35.2, « ACL étendue : éléments d'ACL comparés aux bits de droits d'accès ».

Figure 35.2. ACL étendue : éléments d'ACL comparés aux bits de droits d'accès

Cette approche de mise en correspondance assure une interaction harmonieuse des applications, qu'elles disposent ou non de la prise en charge des ACL. Les droits d'accès qui ont été affectés au moyen des bits de droits d'accès représentent la limite supérieure pour tous les autres « réglages fins » effectués avec une ACL. Les changements apportés aux bits de droits d'accès sont reflétés par l'ACL et vice versa.

La gestion des ACL d'accès est expliquée dans l'exemple suivant :

Avant de créer le répertoire, utilisez la commande umask pour définir quels droits d'accès doivent être masqués chaque fois qu'un objet fichier est créé. La commande umask 027 règle les droits par défaut en donnant au propriétaire l'étendue complète des droits d'accès (0), en refusant au l'accès en écriture (2) et en ne donnant aucun droit du tout aux autres utilisateurs (7). La commande umask masque véritablement les bits de droits d'accès correspondants ou les désactive. Pour plus de détails, consultez la page de manuel correspondante (man umask).

mkdir monrep devrait créer le répertoire monrep avec les droits d'accès par défaut, comme défini par umask. Faites appel à ls -dl monrep pour vérifier si tous les droits ont été affectés correctement. La sortie de cet exemple est :

drwxr-x--- ... tux projet3 ... monrep

Avec getfacl monrep, vérifiez l'état initial de l'ACL. Celle-ci donne des informations comme :

# file: monrep 
# owner: tux 
# group: projet3 
user::rwx 
group::r-x 
other::---
     

La sortie de getfacl reflète précisément la mise en correspondance de bits de droits d'accès avec des éléments d'ACL, comme décrit dans Section 35.3.1, « Éléments d'ACL et bits de droits d'accès du mode fichier ». Les trois premières lignes de la sortie affichent le nom, le propriétaire et le groupe propriétaire du répertoire. Les trois lignes suivantes contiennent les trois éléments d'ACL owner, owning group et other. En fait, dans le cas de cette ACL minimale, la commande getfacl ne produit aucune information que vous n'auriez pu obtenir avec ls.

Modifiez l'ACL pour affecter des droits d'accès en lecture, écriture et exécution à un utilisateur supplémentaire geeko et à un groupe supplémentaire mascottes avec :

setfacl -m user:geeko:rwx,group:mascottes:rwx monrep

L'option -m invite setfacl à modifier l'ACL existante. L'argument suivant indique les éléments d'ACL à modifier (les entrées multiples sont séparées par des virgules). La partie finale spécifie le nom du répertoire auquel ces modifications devront s'appliquer. Utilisez la commande getfacl pour jeter un coup d'œil à l'ACL obtenue.

# file: monrep
# owner: tux
# group: projet3
user::rwx
user:geeko:rwx
group::r-x
group:mascottes:rwx
mask::rwx
other::--- 

En plus des éléments initiés pour l'utilisateur geeko et le groupe mascottes, un élément mask a été généré. Cet élément mask est défini automatiquement, de sorte que tous les droits d'accès sont effectifs. setfacl adapte automatiquement les éléments mask existants aux réglages modifiés, à moins que vous ne désactiviez cette fonctionnalité avec -n. mask définit les droits d'accès effectifs maximaux pour tous les éléments dans le group class. Ceci inclut named user, named group et owning group. Les bits de droit d'accès de group class affichés par ls -dl monrep correspondent à présent à l'élément mask.

drwxrwx---+ ... tux projet3 ... monrep
   

La première colonne de la sortie contient maintenant un + additionnel pour indiquer qu'il y a une ACL étendue pour cet élément.

Selon la sortie de la commande ls, les droits d'accès pour l'élément mask comprennent aussi un accès en écriture. Traditionnellement, de tels bits de droits d'accès signifieraient que le owning group (ici projet3) a aussi un accès en écriture dans le répertoire monrep. Cependant, les droits d'accès effectivement effectifs pour le owning group correspondent à la partie se chevauchant des droits d'accès définis pour le owning group et le mask—qui est r-x dans notre exemple (voir Tableau 35.2, « Masquage de droits d'accès »). Dans la mesure où les droits d'accès effectifs du owning group de cet exemple sont concernés, rien n'a changé, même après l'ajout des éléments d'ACL.

Modifiez l'élément mask avec setfacl ou chmod. Par exemple, faites appel à chmod g-w monrep. ls -dl monrep affiche alors :

drwxr-x---+ ... tux projet3 ... monrep

getfacl monrep fournit la sortie suivante :

# file: monrep
# owner: tux
# group: projet3
user::rwx
user:geeko:rwx          # effective: r-x
group::r-x
group:mascottes:rwx     # effective: r-x
mask::r-x
other::---

Après avoir exécuté la commande chmod pour supprimer le droit d'accès en écriture des bits du group class, la sortie de la commande ls est suffisante pour voir que les bits mask doivent avoir changé en conséquence : le droit d'accès en écriture est à nouveau limité au propriétaire de monrep. La sortie de la commande getfacl le confirme. Cette sortie comporte un commentaire pour tous ces éléments dans lesquels les bits de droits d'accès effectifs ne correspondent pas aux droits d'origine, parce qu'ils ont été filtrés en fonction de l'élément mask. Les droits d'accès d'origine peuvent être restaurés à tout moment avec chmod g+w monrep.

Les répertoires peuvent avoir une ACL par défaut, ce qui est un type spécial d'ACL définissant les droits d'accès dont les objets présents dans le répertoire héritent quand ils sont créés. Une ACL par défaut affecte à la fois les sous-répertoires et les fichiers.

Un algorithme de contrôle est appliqué avant d'accorder à n'importe quel processus ou application l'accès à un objet système de fichiers protégé par des ACL. À titre de règle de base, les éléments sont examinés dans l'ordre suivant :owner, named user, owning group et named group et other. L'accès est géré en conformité avec l'élément qui convient le mieux au processus. Les droits d'accès ne se cumulent pas.

La situation se complique si un processus appartient à plusieurs groupes et pourrait potentiellement convenir à plusieurs éléments group. Un élément est sélectionné aléatoirement parmi les éléments appropriés avec les droits d'accès requis. Le fait de savoir lequel des éléments déclenche le résultat final « accès accordé »n'a pas d'importance. De même, si aucun des éléments group approprié ne contient les droits d'accès exigés, un élément sélectionné aléatoirement déclenche le résultat final « access denied ».