Configuration d'ACL dans des fichiers ZFS

Dans la mesure où elles sont implémentées avec ZFS, les ACL se composent d'un tableau d'entrées d'ACL. ZFS fournit un modèle d'ACL pur, dans lequel tous les fichiers présentent une ACL. L'ACL est habituellement insignifiante dans la mesure où elle ne représente que les entrées UNIX traditionnelles owner/group/other.

Les fichiers ZFS disposent toujours de bits de droit et d'un mode, mais ces valeurs constituent plus un cache de ce que représente une ACL. Par conséquent, si vous modifiez les droits du fichier, son ACL est mise à jour en conséquence. En outre, si vous supprimez une ACL non triviale qui accordait à un utilisateur l'accès à un fichier ou à un répertoire, il est possible que cet utilisateur y ait toujours accès en raison des bits d'autorisation qui accordent l'accès à un groupe ou à tous les utilisateurs. L'ensemble des décisions de contrôle d'accès est régi par les droit représentés dans l'ACL d'un fichier ou d'un répertoire.

Les règles principales d'accès aux ACL dans un fichier ZFS sont comme suit :

• ZFS traite les entrées d'ACL dans l'ordre dans lesquelles elles sont répertoriées dans l'ACL, en partant du haut.

• Seules les entrées d'ACL disposant d'un " who " correspondant au demandeur d'accès sont traitées.

• Une fois le droit allow accordé, ce dernier ne peut plus être refusé par la suite par une entrée d'ACL de refus dans le même jeu de droits d'ACL.

• Le propriétaire du fichier dispose du droit write_acl de façon inconditionnelle, même si celui-ci est explicitement refusé. Dans le cas contraire, tout droit non spécifié est refusé.

  Dans les cas de droits deny ou lorsqu'un droit d'accès est manquant, le sous-système de privilèges détermine la requête d'accès accordée pour le propriétaire du fichier ou pour le superutilisateur. Ce mécanisme évite que les propriétaires de fichiers ne puissent plus accéder à leurs fichiers et permet aux superutilisateurs de modifier les fichiers à des fins de récupération.

Si vous configurez une ACL non triviale dans un répertoire, les enfants du répertoire n'en héritent pas automatiquement. Si vous configurez une ACL non triviale, et souhaitez qu'elle soit héritée par les enfants du répertoire, vous devez utiliser les indicateurs d'héritage d'ACL. Pour plus d'informations, consultez le Tableau 8-3 et la section Configuration d'héritage d'ACL dans des fichiers ZFS en format détaillé.

Lorsque vous créez un fichier, en fonction de la valeur umask, une ACL triviale par défaut, similaire à la suivante, est appliquée :

$ ls -v file.1
-rw-r--r--   1 root     root      206663 Jun 23 15:06 file.1
     0:owner@:read_data/write_data/append_data/read_xattr/write_xattr
         /read_attributes/write_attributes/read_acl/write_acl/write_owner
         /synchronize:allow
     1:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
     2:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Chaque catégorie d'utilisateur (owner@, group@, everyone@) dispose d'une entrée d'ACL dans cet exemple.

Voici une description de l'ACL de ce fichier :

0:owner@

Le propriétaire peut lire et modifier le contenu du fichier (read_data/write_data/append_data). Il peut également modifier les attributs du fichier tels que les horodatages, les attributs étendus et les ACL (write_xattr/write_attributes /write_acl). Le propriétaire peut également modifier la propriété du fichier (write_owner:allow).

Le droit d'accès synchronize n'est actuellement pas implémenté.

1:group@

Les autorisations de lecture du fichier et de ses attributs sont attribuées au groupe (read_data/read_xattr/read_attributes/read_acl:allow).

2:everyone@

Les autorisations de lecture du fichier et de ses attributs sont attribués à toute personne ne correspondant ni à un utilisateur ni à un groupe (read_data/read_xattr/read_attributes/read_acl/synchronize:allow ). Le droit d'accès synchronize n'est actuellement pas implémenté.

Lorsqu'un répertoire est créé, en fonction de la valeur umask, l'ACL par défaut du répertoire est similaire à l'exemple suivant :

$ ls -dv dir.1
drwxr-xr-x   2 root     root           2 Jun 23 15:06 dir.1
     0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/read_attributes
         /write_attributes/read_acl/write_acl/write_owner/synchronize:allow
     1:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     2:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Voici une description de l'ACL de ce répertoire :

0:owner@

Le propriétaire peut lire et modifier le contenu du répertoire (list_directory/read_data/add_file/write_data/add_subdirectory/append_data ), effectuer des recherches dans le contenu (execute) et modifier les attributs du fichier, notamment les horodatages, les attributs étendus et les ACL (/read_xattr/write_xattr/read_attributes/write_attributes/read_acl/write_acl ). De plus, le propriétaire peut modifier la propriété du répertoire (write_owner:allow).

Le droit d'accès synchronize n'est actuellement pas implémenté.

1:group@

Le groupe peut répertorier et lire le contenu et les attributs du répertoire. De plus, le groupe dispose d'autorisations d'exécution pour effectuer des recherches dans le contenu du répertoire (list_directory/read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow).

2:everyone@

Toute personne n'étant ni un utilisateur ni un groupe dispose de droits de lecture et d'exécution sur le contenu et les attributs du répertoire (list_directory/read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow ). Le droit d'accès synchronize n'est actuellement pas implémenté.