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. En règle générale, cette liste est triviale dans la mesure où elle ne représente que les entrées propriétaire/groupe/autre UNIX classiques.
Les fichiers ZFS disposent toujours de bits d'autorisation et d'un mode, mais ces valeurs constituent plutôt un cache de ce que représente une ACL. Par conséquent, si vous modifiez les autorisations 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 autorisations représentées 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 l'autorisation accordée, cette dernière ne peut plus être refusée par la suite par une entrée d'ACL dans le même jeu de d'autorisations d'ACL.
Le propriétaire du fichier dispose de l'autorisation write_acl de façon inconditionnelle, même si celle-ci est explicitement refusée. Dans le cas contraire, toute autorisation non spécifiée est refusée.
Dans les cas d'autorisations deny ou lorsqu'une autorisation d'accès est manquante, le sous-système de privilèges détermine la demande 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 puissent 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, reportez-vous au Table 7–4 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 fichier catégorie d'utilisateur (owner@, group@, everyone@) dispose d'une entrée ACL dans l'exemple ci-dessous.
Voici une description de l'ACL de ce fichier :
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). De plus, le propriétaire peut modifier la propriété du fichier (write_owner).
L'autorisation d'accès synchronize n'est actuellement pas implémentée.
Les autorisations de lecture du fichier et de ses attributs sont attribuées au groupe (read_data/read_xattr/read_attributes/read_acl:allow).
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 ). L'autorisation d'accès synchronize n'est actuellement pas implémentée.
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 Jul 20 13:44 dir.1 0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory /append_data/read_xattr/write_xattr/execute/delete_child /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
Une description de ce répertoire est le suivant :
Le propriétaire peut lire et modifier le contenu du répertoire (list_directory/read_data/add_file/write_data/add_subdirectory/append_data ) et lire et modifier les attributs du fichier tels que les horodatages, les attributs étendus et les ACL (/read_xattr/write_xattr/read_attributes/write_attributes/read_acl/write_acl ). En outre, le propriétaire peut faire des recherches dans le contenu (execute), supprimer un fichier ou un répertoire (delete_child) et modifier la possession du répertoire (write_owner:allow).
L'autorisation d'accès synchronize n'est actuellement pas implémentée.
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).
Toute personne n'étant ni un utilisateur ni un groupe dispose d'autorisations 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 ). L'autorisation d'accès synchronize n'est actuellement pas implémentée.