5.4. Gestion des ACL

Le Tableau 5.1, « Types d'entrées ACL » présente les six types possibles d'entrées ACL, chacun définissant les autorisations d'un utilisateur ou d'un groupe d'utilisateurs. L'entrée propriétaire définit les autorisations de l'utilisateur propriétaire du fichier ou du répertoire. L'entrée groupe propriétaire définit les autorisations du groupe propriétaire du fichier. Le superutilisateur peut modifier le propriétaire ou le groupe propriétaire via l'une des commandes chown ou chgrp. Dans ce cas, les entrées du propriétaire et du groupe propriétaire font référence au nouveau propriétaire et au nouveau groupe propriétaire. Chaque entrée utilisateur nommé définit les autorisations de l'utilisateur spécifié dans le champ de qualification de l'entrée. Chaque entrée groupe nommé définit les autorisations du groupe spécifié dans le champ de qualification de l'entrée. Seules les entrées d'utilisateur nommé et de groupe nommé disposent d'un champ de qualification qui n'est pas vide. L'entrée autre définit les autorisations de tous les autres utilisateurs.

L'entrée masque limite davantage les autorisations accordées par les entrées utilisateur nommé, groupe nommé et groupe propriétaire en définissant, parmi ces entrées, les autorisations qui sont en vigueur et celles qui sont masquées. Si des autorisations sont paramétrées dans l'une des entrées mentionnées ainsi que dans le masque, elles sont en vigueur. Les autorisations contenues uniquement dans le masque ou uniquement dans l'entrée à proprement parler ne sont pas en vigueur, et ne sont pas accordées. Toutes les autorisations définies dans les entrées propriétaire et groupe propriétaire sont toujours en vigueur. L'exemple du Tableau 5.2, « Masquage des autorisations d'accès » illustre ce mécanisme.

Il existe deux classes basiques d'ACL : une ACL minimum contient uniquement les entrées des types propriétaire, groupe propriétaire et autre, qui correspondent aux bits conventionnels d'autorisation pour les fichiers et les répertoires. Une ACL étendue va plus loin. Elle doit contenir une entrée masque et peut contenir plusieurs entrées de type utilisateur nommé et groupe nommé.

Tableau 5.1. Types d'entrées ACL

Type

Forme textuelle

propriétaire

user::rwx

utilisateur nommé

user:name:rwx

groupe propriétaire

group::rwx

groupe nommé

group:name:rwx

masque

mask::rwx

autre

other::rwx

Tableau 5.2. Masquage des autorisations d'accès

Type d'entrée

Forme textuelle

Autorisations

utilisateur nommé

user:geeko:r-x

r-x

masque

mask::rw-

rw-

autorisations en vigueur :

r--

5.4.1. Entrées ACL et bits d'autorisation en mode fichier

La Figure 5.1, « ACL minimum : entrées ACL comparées aux bits d'autorisation » et la Figure 5.2, « ACL étendue : entrées ACL comparées aux bits d'autorisation » illustrent les deux cas d'ACL minimum et d'ACL étendue. Les figures sont structurées en trois blocs : le bloc de gauche représente les spécifications de type des entrées ACL, le bloc central affiche un exemple d'ACL et le bloc de droite représente les bits d'autorisation correspondants selon le concept d'autorisation conventionnel, par exemple, tel qu'ils sont affichés par la commande ls -l. Dans les deux cas, les autorisations de la classe propriétaire sont assignées à l'entrée ACL propriétaire. Les autorisations Autre classe sont assignées à l'entrée ACL correspondante. Cependant, l'assignation des autorisations classe de groupe est différente dans les deux cas.

Figure 5.1. ACL minimum : entrées ACL comparées aux bits d'autorisation

ACL minimum : entrées ACL comparées aux bits d'autorisation

Dans le cas d'une ACL minimum, sans masque, les autorisations de la classe de groupe sont assignées à l'entrée ACL groupe propriétaire. Il est présenté dans la Figure 5.1, « ACL minimum : entrées ACL comparées aux bits d'autorisation ». Dans le cas d'une ACL étendue, avec masque, les autorisations de la classe de groupe sont assignées à l'entrée masque. Il est présenté dans la Figure 5.2, « ACL étendue : entrées ACL comparées aux bits d'autorisation ».

Figure 5.2. ACL étendue : entrées ACL comparées aux bits d'autorisation

ACL étendue : entrées ACL comparées aux bits d'autorisation

Cette approche d'assignation garantit l'interaction régulière des applications, qu'elles prennent en charge les ACL ou non. Les autorisations d'accès qui ont été assignées au moyen des bits d'autorisation représentent la limite supérieure de tous les autres « paramétrages avancés » effectués avec une ACL. Les modifications apportées aux bits d'autorisation sont reflétées par l'ACL et inversement.

5.4.2. Répertoire avec une ACL d'accès

Avec getfacl et setfacl sur la ligne de commande, vous pouvez accéder aux ACL. L'utilisation de ces commandes est présentée dans l'exemple suivant.

Avant de créer le répertoire, utilisez la commande umask pour définir les autorisations d'accès qui doivent être masquées chaque fois qu'un objet Fichier est créé. La commande umask 027 définit les autorisations par défaut en donnant au propriétaire toute la plage d'autorisations (0), en refusant au groupe l'accès en écriture (2) et en ne donnant aucune autorisation aux autres utilisateurs (7). En fait, umask masque les bits d'autorisation correspondants ou les désactive. Pour plus d'informations, reportez-vous à la page de manuel umask.

mkdir monrép crée le répertoire monrép avec les autorisations par défaut telles qu'elles sont définies par umask. Utilisez ls -dl monrép pour vérifier si toutes les permissions ont été assignées correctement. Voici la sortie de cet exemple :

 
drwxr-x--- ... tux projet3 ... monrép

Avec getfacl monrép, vérifiez l'état initial de l'ACL. Vous obtenez des informations telles que :

# file: monrép 
# owner: tux 
# group: projet3 
user::rwx 
group::r-x 
other::--- 
     

Les trois premières lignes de sortie affichent le nom, le propriétaire et le groupe propriétaire du répertoire. Les trois lignes suivantes contiennent les trois entrées ACL propriétaire, groupe propriétaire et autre. En fait, dans le cas de l'ACL minimum, la commande getfacl ne génère pas plus d'informations que la commande ls.

Modifiez l'ACL pour assigner des autorisations en lecture, écriture et exécution à l'utilisateur supplémentaire geeko et au groupe supplémentaire mascots, de la manière suivante :

 
setfacl -m user:geeko:rwx,group:mascots:rwx monrép

L'option -m demande à setfacl de modifier l'ACL existante. L'argument suivant désigne les entrées ACL à modifier (des entrées multiples sont séparées par des virgules). La partie finale indique le nom du répertoire dans lequel ces modifications doivent être appliquées. Utilisez la commande getfacl pour consulter l'ACL obtenue.

   # file: monrép 
   # owner: tux 
   # group: projet3 user::rwx 
   user:geeko:rwx group::r-x 
   group:mascots:rwx mask::rwx 
   other::--- 
   

En plus des entrées lancées pour l'utilisateur geeko et le groupe mascots, une entrée mask a été générée. Cette entrée de masque est définie automatiquement afin que toutes les autorisations entrent en vigueur. setfacl adapte automatiquement les entrées mask aux paramètres modifiés à moins que vous ne désactiviez cette fonctionnalité avec -n. mask définit les autorisations d'accès maximum en vigueur pour toutes les entrées de la classe de groupe, notamment l'utilisateur nommé, le groupe nommé et le groupe propriétaire. Les bits d'autorisation de la classe de groupe affichés via ls -dl monrép correspondent maintenant à l'entrée mask.

 
drwxrwx---+ ... tux projet3 ... monrép 
   

La première colonne de la sortie contient un signe + qui indique que cet élément possède une ACL étendue.

En fonction de la sortie de la commande ls, les autorisations de l'entrée de masque comprennent l'accès en écriture. Généralement, de tels bits d'autorisation signifient que le groupe propriétaire (ici projet3) dispose également d'un accès en écriture au répertoire monrép. Cependant, les autorisations d'accès en vigueur du groupe propriétaire correspondent à la partie commune avec les autorisations définies pour le groupe propriétaire et le masque (r-x dans notre exemple) (reportez-vous au Tableau 5.2, « Masquage des autorisations d'accès »). En ce qui concerne les autorisations en vigueur du groupe propriétaire de cet exemple, rien n'a été modifié même après l'ajout des entrées ACL.

Modifiez l'entrée du masque avec setfacl ou chmod. Par exemple, utilisez chmod g-w monrép. ls -dl monrép affiche ensuite :

 
drwxr-x---+ ... tux projet3 ... monrép 

getfacl monrép génère la sortie suivante :

# file: monrép 
# owner: tux 
# group: projet3 
user::rwx 
user:geeko:rwx          # effective: r-x 
group::r-x 
group:mascots:rwx      # effective: r-x 
mask::r-x 
other::--- 

Une fois que vous avez exécuté la commande chmod pour supprimer l'autorisation en écriture des bits de la classe de groupe, la sortie de la commande ls suffit pour savoir que les bits de masque doivent être modifiés en conséquence : l'autorisation en écriture est à nouveau limitée au propriétaire de monrép. La sortie de getfacl confirme ce fait. Cette sortie comprend un commentaire pour toutes les entrées dans lesquelles les bits d'autorisation en vigueur ne correspondent pas aux autorisations d'origine, car elles sont filtrées en fonction de l'entrée de masque. Les autorisations d'origine peuvent être restaurées à tout moment avec chmod g+w monrép.

5.4.3. Répertoire avec une ACL par défaut

Les répertoires peuvent avoir une ACL par défaut, type spécial d'ACL qui définit les autorisations d'accès dont les objets du répertoire héritent lors de leur création. Une ACL par défaut a un effet sur les sous-répertoires et les fichiers.

5.4.3.1. Effets d'une ACL par défaut

Il existe deux manières de transmettre les autorisations d'une ACL par défaut d'un répertoire aux fichiers et aux sous-répertoires qu'il contient :

  • Un sous-répertoire hérite de l'ACL par défaut du répertoire parent en tant qu'ACL par défaut et ACL d'accès.

  • Un fichier hérite d'une ACL par défaut en tant qu'ACL d'accès.

Tous les appels système qui créent des objets Système de fichiers utilisent un paramètre mode qui définit les autorisations d'accès pour le nouvel objet Système de fichiers. Si le répertoire parent ne dispose pas d'une ACL par défaut, les bits d'autorisation définis par umask sont soustraits des autorisations transmises par le paramètre mode, le résultat étant assigné au nouvel objet. Si le répertoire parent possède une ACL par défaut, les bits d'autorisation assignés au nouvel objet correspondent à la partie commune des autorisations du paramètre mode et à celles définies dans l'ACL par défaut. umask est ignoré dans ce cas.

5.4.3.2. Application des ACL par défaut

Les trois exemples suivants présentent les principales opérations des répertoires et des ACL par défaut :

  1. Ajoutez une ACL par défaut au répertoire existant monrép à l'aide de :

     
    setfacl -d -m group:mascots:r-x monrép 
    

    L'option -d de la commande setfacl demande à setfacl d'apporter les modifications suivantes (option -m) à l'ACL par défaut.

    Regardez plus attentivement le résultat de cette commande :

     
    getfacl monrép
    
    # file: monrép 
    # owner: tux 
    # group: projet3 
    user::rwx 
    user:geeko:rwx 
    group::r-x 
    group:mascots:rwx 
    mask::rwx 
    other::--- 
    default:user::rwx 
    default:group::r-x 
    default:group:mascots:r-x 
    default:mask::r-x 
    default:other::--- 
    

    getfacl retourne l'ACL d'accès et l'ACL par défaut. L'ACL par défaut est constituée de toutes les lignes commençant par default. Bien que vous ayez simplement exécuté la commande setfacl avec une entrée pour le groupe mascots de l'ACL par défaut, setfacl a automatiquement copié toutes les autres entrées de l'ACL d'accès pour créer une ACL par défaut valide. Les ACL par défaut n'ont pas d'effet immédiat sur les autorisations d'accès. Elles entrent uniquement en jeu lorsque des objets Système de fichiers sont créés. Ces nouveaux objets héritent des autorisations provenant uniquement de l'ACL par défaut de leur répertoire parent.

  2. Dans l'exemple suivant, utilisez mkdir pour créer dans monrép un sous-répertoire qui hérite de l'ACL par défaut.

     
    mkdir monrép/monsousrép
    
    getfacl monrép/monsousrép
    
    # file: monrép/monsousrép 
    # owner: tux 
    # group: projet3 
    user::rwx 
    group::r-x 
    group:mascots:r-x 
    mask::r-x 
    other::--- 
    default:user::rwx 
    default:group::r-x 
    default:group:mascots:r-x 
    default:mask::r-x 
    default:other::--- 
    

    Comme prévu, le nouveau répertoire monsousrép dispose des autorisations de l'ACL par défaut du répertoire parent. L'ACL d'accès de monsousrép est le reflet exact de l'ACL par défaut de monrép. L'ACL par défaut que ce répertoire doit transmettre à ses objets subordonnés est également identique.

  3. Utilisez touch pour créer un fichier dans le répertoire monrép, par exemple, touch monrép/monfichier. ls -l monrép/monfichier affiche ensuite :

     
    -rw-r-----+ ... tux projet3 ... monrép/monfichier 
    

    La sortie de getfacl monrép/monfichier est la suivante :

    # file: monrép/monfichier 
    # owner: tux 
    # group: projet3 
    user::rw- 
    group::r-x          # effective:r-- 
    group:mascots:r-x   # effective:r-- 
    mask::r-- 
    other::--- 
    

    touch utilise un paramètre mode avec la valeur 0666 lors de la création de fichiers. Les fichiers sont donc créés avec des autorisations en lecture/écriture pour toutes les classes d'utilisateurs, à condition qu'il n'existe aucune autre restriction dans umask ou dans l'ACL par défaut (reportez-vous à Section 5.4.3.1, « Effets d'une ACL par défaut »). Autrement dit, toutes les autorisations d'accès qui ne sont pas contenues dans la valeur mode sont supprimées des entrées ACL correspondantes. Bien qu'aucune autorisation n'ait été supprimée de l'entrée ACL de la classe de groupe, l'entrée de masque a été modifiée en autorisations de masque non définies dans le paramètre mode.

    Cette approche garantit l'interaction correcte des applications, notamment des compilateurs, avec les ACL. Vous pouvez créer des fichiers avec des autorisations d'accès limitées et les marquer ultérieurement comme exécutables. Le mécanisme de masque garantit que les utilisateurs et les groupes corrects peuvent les exécuter selon leurs besoins.

5.4.4. Algorithme de contrôle des ACL

Un algorithme de contrôle est appliqué avant qu'un processus ou une application n'obtienne l'accès à un objet Système de fichiers protégé par ACL. En règle générale, les entrées ACL sont examinées dans l'ordre suivant : propriétaire, utilisateur nommé, groupe propriétaire ou groupe nommé et autre. L'accès est géré conformément à l'entrée qui correspond le mieux au processus. Les autorisations ne se cumulent pas.

Les choses sont plus compliquées si un processus appartient à plusieurs groupes et risque d'être adapté à plusieurs entrées de groupe. Une entrée est aléatoirement sélectionnée dans les entrées adaptées avec les autorisations nécessaires. Peu importe l'entrée qui déclenche le résultat final « accès accordé ». De même, si aucune des entrées adaptées du groupe ne contient les autorisations nécessaires, une entrée sélectionnée de manière aléatoire déclenche le résultat final « accès refusé ».