Guide d'administration Oracle Solaris ZFS

Chapitre 8 Utilisation des ACL pour protéger les fichiers Oracle Solaris ZFS

Ce chapitre explique comment utiliser des ACL (Access Control List) pour protéger les fichiers ZFS. Les ACL octroient des droits d'accès plus granulaires que les droits d'accès UNIX standard.

Il contient les sections suivantes :

Nouveau modèle ACL Solaris

Les versions précédentes du système d'exploitation Solaris assuraient la prise en charge d'une implémentation ACL reposant principalement sur la spécification d'ACL POSIX-draft. Les ACL basées sur POSIX-draft sont utilisées pour protéger les fichiers UFS et sont traduites par les versions de NFS antérieures à NFSv4.

Grâce à l'introduction de NFSv4, un nouveau modèle d'ACL assure entièrement la prise en charge de l'interopérabilité qu'offre NFSv4 entre les clients UNIX et non UNIX. La nouvelle implémentation d'ACL, telle que définie dans les spécifications NFSv4, fournit des sémantiques bien plus riches, basées sur des ACL NT.

Les principales différences du nouveau modèle ACL sont les suivantes :

Le nouveau modèle ACL est basé sur la spécifications NFSv4 et est similaire aux ACL de type Windows NT.
Ce nouveau modèle fournit un jeu d'autorisations d'accès plus détaillé. Pour plus d'informations, reportez-vous au Tableau 8–2.
Les ACL sont définies et affichées avec les commandes chmod et ls plutôt qu'avec les commandes setfacl et getfacl.
Le nouveau modèle propose une sémantique héritée plus riche pour définir l'application des privilèges d'accès du répertoire aux sous-répertoires, etc. Pour plus d'informations, reportez-vous à la section Héritage d'ACL.

Les deux modèles d'ACL assurent un contrôle d'accès bien plus fin, et disponible avec les droits de fichier standard. De façon similaire aux listes de contrôle d'accès POSIX-draft, les nouvelles ACL se composent de plusieurs ACE (Access Control Entry, entrées de contrôle d'accès).

Les ACL POSIX-draft utilisent une seule entrée pour définir les permissions autorisées et celles qui ne le sont pas. Le nouveau modèle d'ACL dispose de deux types d'ACE qui affectent la vérification d'accès : ALLOW et DENY. Par conséquent, il est impossible de déduire de toute entrée de contrôle d'accès (ACE, Access Control Entry) définissant un groupe de droits si les droits qui n'ont pas été définis dans cette ACE sont ou non autorisés.

La conversion entre les ACL NFSv4 et les ACL POSIX-draft s'effectue comme suit :

Si vous employez un utilitaire compatible avec les ACL (les commandes cp, mv, tar, cpio ou rcp, par exemple) pour transférer des fichiers UFS avec des ACL vers un système de fichiers ZFS, les ACL POSIX-draft sont converties en ACL NFSv4 équivalentes.
Certaines ACL NFSv4 sont converties en ACL POSIX. Si une ACL NFSv4 n'a pas été convertie en ACL POSIX, un message tel que le suivant s'affiche :
# cp -p filea /var/tmp cp: failed to set acl entries on /var/tmp/filea
Si vous créez une archive cpio ou tar UFS avec l'option de conservation des ACL (tar -p ou cpio -P) dans un système exécutant la version actuelle de Solaris, les ACL sont perdues en cas d'extraction de l'archive sur un système exécutant une version précédente de Solaris.

Tous les fichiers sont extraits avec les modes de fichier corrects, mais les entrées d'ACL sont ignorées.
Vous pouvez utiliser la commande ufsrestore pour restaurer des données dans un système de fichiers ZFS. Si les données d'origine contiennent des ACL POSIX, ces dernières sont converties en ACL NFSv4.
Si vous tentez de définir une ACL NFSv4 dans un fichier UFS, un message tel que le suivant s'affiche :
chmod: ERROR: ACL type's are different

Si vous tentez de définir une ACL POSIX dans un fichier UFS, des messages tels que les suivants s'affichent :

# getfacl filea
File system doesn't support aclent_t style ACL's.
See acl(5) for more information on Solaris ACL support.

Pour obtenir des informations sur les autres limitations des ACL et des produits de sauvegarde, reportez-vous à la section Enregistrement de données ZFS à l'aide d'autres produits de sauvegarde.

Descriptions de syntaxe pour la configuration des ACL

Les deux formats de base des ACL sont les suivants :

Syntax for Setting Trivial ACLs

Une ACL constitue un élément trivial : elle représente uniquement les entrées UNIX owner/group/other standard.

chmod [options] A[index]{+|=}owner@ |group@ |everyone@: droits d'accès/...[:indicateurs d'héritage]: deny | allow fichier

chmod [options] A-owner@, group@, everyone@:droits d'accès /...[:indicateurs d'héritage]:deny | allow fichier ...

chmod [options] A[index]- fichier

Syntaxe pour la configuration d'ACL non triviales

chmod [options] A[index]{+|=}user|group:name:droits d'accès /...[:indicateurs d'héritage]:deny | allow fichier

chmod [options] A-user|group:name:droits d'accès /...[:indicateurs d'héritage]:deny | allow fichier ...

chmod [options] A[index]- fichier

owner@, group@, everyone@: Identifie le type d'entrée d'ACL pour la syntaxe d'ACL triviale. Pour obtenir une description des types d'entrée d'ACL, reportez-vous au Tableau 8–1.
user ou group:ACL-entry-ID=username or groupname: Identifie le type d'entrée d'ACL pour la syntaxe d'ACL explicite. Les types d'entrées d'ACL user et group doivent également contenir les éléments suivants : ACL-entry-ID, username ou groupname. Pour obtenir une description des types d'entrée d'ACL, reportez-vous au Tableau 8–1.
droits-accès/.../: Identifie les droits d'accès accordés ou refusés. Pour obtenir une description des privilèges d'accès d'ACL, reportez-vous au Tableau 8–2.
indicateurs-héritage: Identifie une liste optionnelle d'indicateurs d'héritage d'ACL. Pour une description des indicateurs d'héritage d'ACL, reportez-vous au Tableau 8–3.
deny | allow: Détermine si les droits d'accès sont accordés ou refusés.

Dans l'exemple suivant, la valeur de l'ID d'entrée d'ACL n'est pas pertinente :

group@:write_data/append_data/execute:deny

L'exemple suivant inclut un ID d'entrée d'ACL car un utilisateur spécifique (type d'entrée d'ACL) est inclus dans la liste.

0:user:gozer:list_directory/read_data/execute:allow

Lorsqu'une entrée d'ACL s'affiche, elle est similaire à celle-ci :

2:group@:write_data/append_data/execute:deny

Dans l'exemple suivant, la valeur 2, à savoir la désignation de la propriété ID d'index, permet d'identifier l'entrée ACL dans la plus grande ACL qui peut présenter plusieurs entrées pour le propriétaire, des UID spécifiques, des groupes et pour tous. Vous pouvez spécifier l'ID d'index avec la commande chmod pour identifier la partie de l'ACL que vous souhaitez modifier. Par exemple, vous pouvez identifier l'ID de l'index 3 A3 en utilisant une syntaxe de commande chmod semblable à la syntaxe suivante :

chmod A3=user:venkman:read_acl:allow filename

Les types d'entrées d'ACL (qui sont les représentations d'ACL du propriétaire, du groupe et autres) sont décrits dans le tableau suivant.

Tableau 8–1 Types d'entrées d'ACL


Type d'entrée d'ACL	Description
`owner@`	Spécifie l'accès accordé au propriétaire de l'objet.
`group@`	Spécifie l'accès accordé au groupe propriétaire de l'objet.
`everyone@`	Spécifie l'accès accordé à tout utilisateur ou groupe ne correspondant à aucune autre entrée d'ACL.
`user`	Avec un nom d'utilisateur, spécifie l'accès accordé à un utilisateur supplémentaire de l'objet. Cette entrée doit comprendre l'ID d'entrée ACL contenant un `nom d'utilisateur` ou un `ID d'utilisateur`. Le type d'entrée d'ACL est incorrect si la valeur n'est ni un UID numérique, ni un `nom d'utilisateur`.
`group`	Avec un nom de groupe, spécifie l'accès accordé à un utilisateur supplémentaire de l'objet. Cette entrée doit comprendre l'ID d'entrée ACL contenant un `nom de groupe` ou un `ID de groupe`. Le type d'entrée d'ACL est incorrect si la valeur n'est ni un GID numérique, ni un `nom de groupe`.

Les privilèges d'accès sont décrits dans le tableau suivant.

Tableau 8–2 Privilèges d'accès d'ACL


Privilège d'accès	Privilège d'accès compact	Description
`add_file`	`w`	Droit d'ajouter un fichier à un répertoire.
`add_subdirectory`	`p`	Dans un répertoire, droit de créer un sous-répertoire.
`append_data`	`p`	Marque de réservation. Non implémentée actuellement.
`delete`	`d`	Droit de supprimer un fichier.
`delete_child`	`D`	Droit de supprimer un fichier ou un répertoire au sein d'un répertoire.
`execute`	`x`	Droit d'exécuter un fichier ou d'effectuer une recherche dans le contenu d'un répertoire.
`list_directory`	`r`	Droit de dresser la liste du contenu d'un répertoire.
`read_acl`	`c`	Droit de lire l'ACL (`ls`).
`read_attributes`	`a`	Droit de lire les attributs de base (non ACL) d'un fichier. Considérez les attributs de base comme les attributs de niveau stat. L'autorisation de ce bit de masque d'accès signifie que l'entité peut exécuter `ls`(1) et `stat`(2).
`read_data`	`r`	Droit de lire les informations d'un fichier.
`read_xattr`	`R`	Droit de lire les attributs d'un fichier ou d'effectuer une recherche dans le répertoire d'attributs étendus d'un fichier.
`synchronize`	`s`	Marque de réservation. Non implémentée actuellement.
`write_xattr`	`W`	Droit de créer des attributs étendus ou d'écrire dans le répertoire d'attributs étendus. L'attribution de ce droit à un utilisateur signifie que ce dernier peut créer un répertoire d'attributs étendus pour un fichier. Les droits du fichier d'attributs contrôlent l'accès de l'utilisateur à l'attribut.
`write_data`	`w`	Droit de modifier ou de remplacer le contenu d'un fichier.
`write_attributes`	`A`	Droit de remplacer les horodatages associés à fichier ou un répertoire par une valeur arbitraire.
`write_acl`	`C`	Droit d'écriture sur l'ACL ou de modification de celle-ci à l'aide de la commande `chmod`.
`write_owner`	`o`	Droit de modifier le propriétaire ou le groupe d'un fichier. Ou capacité d'exécuter les commandes `chown` ou `chgrp` sur le fichier. Droit de devenir propriétaire d'un fichier ou droit de définir la propriété de groupe du fichier sur un groupe dont fait partie l'utilisateur. Le privilège `PRIV_FILE_CHOWN` est requis pour définir la propriété de fichier ou de groupe sur un groupe ou un utilisateur arbitraire.

Héritage d'ACL

L'héritage d'ACL a pour finalité de permettre à un fichier ou répertoire d'hériter des ACL qui lui sont destinées, tout en tenant compte des droits existants du répertoire parent.

Par défaut, les ACL ne sont pas propagées. Si vous définissez une ACL non triviale sur un répertoire, les répertoires enfant n'en héritent pas. Vous devez spécifier l'héritage d'une ACL dans un fichier ou un répertoire.

Les indicateurs d'héritage facultatifs sont décrits dans le tableau suivant.

Tableau 8–3 Indicateurs d'héritage d'ACL


Indicateur d'héritage	Indicateur d'héritage compact	Description
`file_inherit`	`f`	Hérite de l'ACL à partir du répertoire parent mais s'applique uniquement aux fichiers du répertoire.
`dir_inherit`	`d`	Hérite de l'ACL à partir du répertoire parent mais s'applique uniquement au sous-répertoires du répertoire.
`inherit_only`	`i`	Hérite de l'ACL à partir du répertoire parent mais ne s'applique qu'aux fichiers et sous-répertoires récemment créés, pas au répertoire lui-même. Cet indicateur requiert les indicateurs `file_inherit` et/ou `dir_inherit` afin de spécifier ce qui doit être hérité.
`no_propagate`	`n`	N'hérite que de l'ACL provenant du répertoire parent vers le contenu de premier niveau du répertoire, et non les contenus de second niveau et suivants. Cet indicateur requiert les indicateurs `file_inherit` et/ou `dir_inherit` afin de spécifier ce qui doit être hérité.
`-`	SO	Aucun droit n'est accordé.

De plus, vous pouvez configurer un héritage d'ACL par défaut plus ou moins strict sur le système de fichiers à l'aide de la propriété de système de fichiers aclinherit. Pour de plus amples informations, consultez la section suivante.

Propriétés ACL

Un système de fichiers ZFS contient deux propriétés en rapport avec les ACL.

aclinherit – Cette propriété détermine le comportement de l'héritage d'ACL. Les valeurs possibles sont les suivantes :
- discard – Pour les nouveaux objets, aucune entrée d'ACL n'est héritée lors de la création d'un fichier ou d'un répertoire. L'ACL dans le nouveau fichier ou répertoire est égale aux permissions du fichier ou répertoire.
- noallow – Pour les nouveaux objets, seules les entrées d'ACL héritables dont le type d'accès est deny sont héritées.
- restricted – Pour les nouveaux objets, les droits write_owner et write_acl sont supprimés lorsqu'une entrée d'ACL est héritée.
- passthrough – Lorsque la valeur de la propriété est définie sur passthrough, les fichiers sont créés avec les permissions déterminées par les ACE héritables. Si aucune ACE pouvant être héritée n'affecte les permissions, celles-ci sont alors définies en fonction des permissions demandées à partir de l'application.
- passthrough-x – Cette valeur de propriété a la même sémantique que passthrough, si ce n'est que lorsque passthrough-x est activé, les fichiers sont créés avec la permission d'exécution ( x), mais uniquement si la permission d'exécution est définie en mode de création de fichier et dans une ACE pouvant être héritée et qui affecte le mode.
La valeur par défaut de la propriété aclinherit est restricted.
aclmode – Cette propriété modifie le comportement des ACL lorsqu'un fichier est créé ou chaque fois que les permissions d'un fichier ou d'un répertoire sont modifiées à l'aide de la commande chmod. Les valeurs possibles sont les suivantes :
- discard – Toutes les entrées d'ACL sont supprimées à l'exception des entrées nécessaires à la définition du mode pour le fichier ou le répertoire.
- groupmask – Les permissions d'ACL de groupe ou d'utilisateur sont réduites de manière à ce qu'elles ne soient pas supérieures aux permission du groupe, à moins qu'il ne s'agisse d'une entrée d'utilisateur ayant le même UID que le propriétaire du fichier ou du répertoire. Ensuite, les permissions d'ACL sont réduites afin qu'elles ne dépassent pas les permissions du propriétaire.
- passthrough – Au cours d'une opération chmod, les ACE autres que owner@, group@ ou everyone@ ne sont modifiées d'aucune manière. Les ACE owner@, group@ ou everyone@ sont désactivées afin de définir le mode de fichier comme demandé par l'opération chmod.
La valeur par défaut de la propriété aclmode est groupmask .

Configuration d'ACL dans des fichiers ZFS

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

Si vous modifiez les permissions du fichier, l'ACL du fichier 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 de permission qui accordent l'accès à un groupe ou à tous. 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 principales règles d'accès aux ACL dans un fichier ZFS sont les suivantes :

ZFS les entrées d'ACL suivant l'ordre dans lesquelles elles sont répertoriées dans l'ACL, de haut en bas.
Seules les entrées d'ACL disposant d'un " who " correspondant au demandeur d'accès sont traitées.
Une fois la permission allow accordée, celle-ci ne peut plus être refusée par une entrée d'ACL deny du même jeu de permissions d'ACL.
Le propriétaire d'un fichier dispose de la permission write_acl de façon inconditionnelle, même si celle-ci est explicitement refusée. Dans le cas contraire, tout droit non spécifié est refusé.

Dans les cas de permissions deny ou lorsqu'une permission d'accès à un fichier est manquante, 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 May 20 14:09 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Notez que chaque catégorie d'utilisateur (owner@, group@, everyone@) dispose de deux entrées ACL dans cet exemple. Une entrée correspond aux permissions deny et une autre aux permissions allow.

La description de l'ACL de ce fichier est la suivante :

0:owner@: Le propriétaire ne dispose pas de la permission d'exécution sur le fichier (execute:deny ).
1:owner@: Le propriétaire peut lire et modifier le contenu d'un fichier ( read_data/write_data/append_data). Le propriétaire 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).
2:group@: Les permissions de modification et d'exécution sur fichier sont refusées au groupe (write_data/append_data/execute:deny).
3:group@: Des droits de lecture du fichier sont accordés au groupe (read_data:allow).
4:everyone@: Tout utilisateur n'étant pas le propriétaire du fichier ou membre du groupe propriétaire du fichier, ne peut ni exécuter, ni modifier les informations ou les attributs d'un fichier (write_data/append_data/write_xattr/execute/write_attributes/write_acl/write_owner:deny ).
5:everyone@: Tout utilisateur n'étant pas le propriétaire du fichier ou membre du groupe propriétaire du fichier dispose de permissions de lecture sur le fichier et ses attributs (lread_data/read_xattr/read_attributes/read_acl/synchronize:allow ). Le droit d'accès synchronize n'est actuellement pas implémenté.

Lorsque vous créez un répertoire dépendant de la valeur umask, un répertoire ACL par défaut, semblable au répertoire ACL suivant, est appliqué :

$ ls -dv dir.1
drwxr-xr-x   2 root     root           2 May 20 14:11 dir.1
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

La description de l'ACL de ce répertoire est la suivante :

0:owner@: La liste deny du propriétaire est vide pour le répertoire (::deny).
1: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 répertoire, 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 répertoire (write_owner:allow).
2:group@: Le groupe ne peut pas ajouter ni modifier le contenu du répertoire (add_file/write_data/add_subdirectory/append_data:deny).
3:group@: Le groupe peut répertorier et lire le contenu du répertoire. De plus, le groupe dispose de droits d'exécution pour effectuer des recherches dans le contenu du répertoire (list_directory/read_data/execute:allow).
4:everyone@: Tout utilisateur n'étant pas le propriétaire du fichier ou membre du groupe propriétaire du fichier ne peut ni ajouter, ni modifier le contenu du répertoire (add_file/write_data/add_subdirectory/append_data). En outre, cet utilisateur ne dispose pas de la permission de modifier les attributs du répertoire (write_xattr/write_attributes/write_acl/write_owner:refuser).
5:everyone@: Tout utilisateur n'étant pas le propriétaire du fichier ou membre du groupe propriétaire du fichier dispose de permissions de lecture et d'exécution sur le contenu et les attributs du répertoire (list_directory/les permissions read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow ). Le droit d'accès synchronize n'est actuellement pas implémenté.

Configuration et affichage d'ACL dans des fichiers ZFS en format détaillé

Vous pouvez modifier les ACL dans des fichiers ZFS à l'aide de la commande chmod. La syntaxe chmod suivante pour la modification de l'ACL utilise la spécification acl pour identifier le format de la liste. Pour obtenir une description de la propriété acl-specification, reportez-vous à la section Descriptions de syntaxe pour la configuration des ACL.

Ajout d'entrées d'ACL
- Ajout d'une entrée d'ACL pour un utilisateur
  % chmod A+acl-specification filename
- Ajout d'une entrée d'ACL par ID d'index
  % chmod Aindex-ID+acl-specification filename
  Cette syntaxe insère la nouvelle entrée d'ACL à l'emplacement d'ID d'index spécifié.

Remplacement d'une entrée d'ACL

% chmod A=acl-specification filename

% chmod Aindex-ID=acl-specification filename

Suppression d'entrées d'ACL
- Suppression d'une entrée d'ACL par l'ID d'index
  % chmod Aindex-ID- filename
- Suppression d'une entrée d'ACL par utilisateur
  % chmod A-acl-specification filename
- Suppression de la totalité des ACE non triviales d'un fichier
  % chmod A- filename

Les informations détaillées de l'ACL s'affichent à l'aide de la commande ls - v. Exemple :

# ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 14:09 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Pour obtenir des informations sur l'utilisation du format d'ACL compact, consultez Configuration et affichage d'ACL dans des fichiers ZFS en format compact.

Exemple 8–1 Modification des ACL triviales dans des fichiers ZFS

Cette section contient des exemples de définition et d'affichage des ACL triviales.

Dans l'exemple suivant, une ACL triviale existe dans le fichier file.1 :

# ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 15:03 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Dans l'exemple suivants, les permissions write_data sont accordées au groupe group@ :

# chmod A2=group@:append_data/execute:deny file.1
# chmod A3=group@:read_data/write_data:allow file.1
# ls -v file.1
-rw-rw-r--   1 root     root      206663 May 20 15:03 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:append_data/execute:deny
     3:group@:read_data/write_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Dans l'exemple suivant, les permissions du fichier file.1 sont reconfigurées sur 644.

# chmod 644 file.1
# ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 15:03 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Exemple 8–2 Configuration d'ACL non triviales dans des fichiers ZFS

Cette section fournit des exemples de configuration et d'affichage d'ACL non triviales.

Dans l'exemple suivant, l'utilisateur gozer dispose de des droits d'accès read_data/execute sur le répertoire test.dir :

# chmod A+user:gozer:read_data/execute:allow test.dir
# ls -dv test.dir
drwxr-xr-x+  2 root     root           2 May 20 15:09 test.dir
     0:user:gozer:list_directory/read_data/execute:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Dans l'exemple suivant, les permissions read_data/execute sont retirées à l'utilisateur gozer :

# chmod A0- test.dir
# ls -dv test.dir
drwxr-xr-x   2 root     root           2 May 20 15:09 test.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Exemple 8–3 Interactions entre les ACL et les droits dans les fichiers ZFS

Ces exemples illustrent l'interaction entre la configuration d'ACL et les modifications des permissions du fichier ou du répertoire.

Dans l'exemple suivant, une ACL triviale existe dans le fichier file.2:

# ls -v file.2
-rw-r--r--   1 root     root        3103 May 20 15:23 file.2
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Dans l'exemple suivant, les permissions d'ACL (allow) sont retirées à everyone@ :

# chmod A5- file.2
# ls -v file.2
-rw-r-----+  1 root     root        3103 May 20 15:23 file.2
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny

Dans cette sortie, les permissions du fichier sont réinitialisées de 644 à 640. Les permissions de lecture pour everyone@ sont supprimées des permissions du fichier lorsque les permissions d'ACL (allow) sont retirées à everyone@.

Dans l'exemple suivant, l'ACL existante est remplacée par des permissions read_data/write_data pour everyone@ :

# chmod A=everyone@:read_data/write_data:allow file.3
# ls -v file.3
-rw-rw-rw-+  1 root     root        6986 May 20 15:25 file.3
     0:everyone@:read_data/write_data:allow

Dans cette sortie, la syntaxe chmod remplace effectivement l'ACL existante par les permissions read_data/write_data:allow pour les permissions de lecture/écriture pour le propriétaire, le groupe et everyone@ . Dans ce modèle, everyone@ spécifie l'accès à tout utilisateur ou groupe. Dans la mesure où aucune entrée d'ACL owner@ ou group@ n'existe pour ignorer les permissions du propriétaire ou du groupe, les permissions sont définies sur 666.

Dans l'exemple suivant, l'ACL existante est remplacée par des permissions de lecture pour l'utilisateur gozer:

# chmod A=user:gozer:read_data:allow file.3
# ls -v file.3
----------+  1 root     root        6986 May 20 15:25 file.3
     0:user:gozer:read_data:allow

Dans cette sortie, les permissions de fichier sont calculées pour êyte 000, car aucune entrée d'ACL n'existe pour owner@, group@ ou everyone@, qui représentent les composants de permission classiques d'un fichier. Le propriétaire du fichier peut résoudre ce problème en réinitialisant les droits (et l'ACL) comme suit :

# chmod 655 file.3
# ls -v file.3
-rw-r-xr-x+  1 root     root        6986 May 20 15:25 file.3
     0:user:gozer::deny
     1:user:gozer:read_data:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data:deny
     5:group@:read_data/execute:allow
     6:everyone@:write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/execute/read_attributes/read_acl
         /synchronize:allow

Exemple 8–4 Restauration des ACL triviales dans des fichiers ZFS

Vous pouvez utiliser la commande chmod pour supprimer les ACL non triviales d'un fichier ou d'un répertoire, ce qui permet de restaurer les ACL triviales du fichier ou du répertoire.

Dans l'exemple suivant, deux ACE non triviales existent dans test5.dir :

# ls -dv test5.dir
drwxr-xr-x+  2 root     root           2 May 20 15:32 test5.dir
     0:user:lp:read_data:file_inherit:deny
     1:user:gozer:read_data:file_inherit:deny
     2:owner@::deny
     3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     4:group@:add_file/write_data/add_subdirectory/append_data:deny
     5:group@:list_directory/read_data/execute:allow
     6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Dans l'exemple suivant, les ACL non triviales pour les utilisateurs gozer et lp sont supprimées. L'ACL restante contient les six valeurs par défaut de owner@, group@ et everyone@.

# chmod A- test5.dir
# ls -dv test5.dir
drwxr-xr-x   2 root     root           2 May 20 15:32 test5.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Configuration d'héritage d'ACL dans des fichiers ZFS en format détaillé

Vous pouvez spécifier les conditions et la façon dont les ACL sont héritées dans les fichiers et les répertoires. Par défaut, les ACL ne sont pas propagées. Si vous configurez une ACL non triviale dans un répertoire, aucun répertoire subséquent n'en hérite. Vous devez spécifier l'héritage d'une ACL dans un fichier ou un répertoire.

En outre, deux propriétés d'ACL sont fournies afin de permettre leur configuration globale dans les systèmes de fichiers : aclinherit et aclmode. Par défaut, aclinherit est définie sur restricted et aclmode sur groupmask .

Pour plus d'informations, reportez-vous à la section Héritage d'ACL.

Exemple 8–5 Attribution d'héritage d'ACL par défaut

Par défaut, les ACL ne sont pas propagées par le biais d'une structure de répertoire.

Dans l'exemple suivant, une ACE non triviale de read_data/write_data/execute est appliquée pour l'utilisateur gozer dans le répertoire test.dir :

# chmod A+user:gozer:read_data/write_data/execute:allow test.dir
# ls -dv test.dir
drwxr-xr-x+  2 root     root           2 May 20 15:41 test.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Si un sous-répertoire test.dir est créé, l'ACE pour l'utilisateur gozer n'est pas propagée. L'utilisateur gozer n'aurait accès au sous-répertoire que si les permissions du sous-répertoire lui accordaient un accès en tant que propriétaire de fichier, membre d'un groupe ou comme faisant partie de la propriété everyone@. Exemple :

# mkdir test.dir/sub.dir
# ls -dv test.dir/sub.dir
drwxr-xr-x   2 root     root           2 May 20 15:42 test.dir/sub.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Exemple 8–6 Attribution d'héritage d'ACL dans les fichiers et les répertoires

Les exemples suivants permettent d'identifier les ACE du fichier et du répertoire qui son appliquées lorsque l'indicateur file_inherit est paramétré.

Dans cet exemple, les permissions read_data/write_data sont ajoutées pour les fichiers dans le répertoire test2.dir pour l'utilisateur gozer pour qu'il dispose de l'accès en lecture à tout nouveau fichier :

# chmod A+user:gozer:read_data/write_data:file_inherit:allow test2.dir
# ls -dv test2.dir
drwxr-xr-x+  2 root     root           2 May 20 15:50 test2.dir
     0:user:gozer:read_data/write_data:file_inherit:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Dans l'exemple suivant, les permissions de l'utilisateur gozer sont appliquées au fichier test2.dir/file.2 récemment créé. L'héritage d'ACL étant accordé (read_data:file_inherit:allow), l'utilisateur gozer peut lire le contenu de tout nouveau fichier.

# touch test2.dir/file.2
# ls -v test2.dir/file.2
-rw-r--r--+  1 root     root           0 May 20 15:51 test2.dir/file.2
     0:user:gozer:write_data:deny
     1:user:gozer:read_data/write_data:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Étant donné que la propriété aclmode de ce fichier est paramétrée sur la valeur par défaut groupmask, l'utilisateur gozer ne dispose pas de la permission write_data pour le fichier file.2 car la permission de groupe du fichier ne le permet pas.

La permission inherit_only appliquée lorsque les indicateurs file_inherit ou dir_inherit sont définis, est utilisées pour propager l'ACL dans la structure du répertoire. Ainsi, l'utilisateur gozer se voit uniquement accorder ou refuser la permission des droits everyone@, à moins qu'il ne soit le propriétaire du fichier ou membre du groupe propriétaire du fichier. Exemple :

# mkdir test2.dir/subdir.2
# ls -dv test2.dir/subdir.2
drwxr-xr-x+  2 root     root           2 May 20 15:52 test2.dir/subdir.2
     0:user:gozer:list_directory/read_data/add_file/write_data:file_inherit
         /inherit_only:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Les exemples suivants identifient les ACL du fichier et du répertoires appliquées, lorsque les indicateurs file_inherit et dir_inherit sont paramétrés.

Dans cet exemple, l'utilisateur gozer se voit accorder les permissions de lecture, d'écriture et d'exécution héritées des fichiers et répertoires récemment créés :

# chmod A+user:gozer:read_data/write_data/execute:file_inherit/dir_inherit:allow 
test3.dir
# ls -dv test3.dir
drwxr-xr-x+  2 root     root           2 May 20 15:53 test3.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :file_inherit/dir_inherit:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

# touch test3.dir/file.3
# ls -v test3.dir/file.3
-rw-r--r--+  1 root     root           0 May 20 15:58 test3.dir/file.3
     0:user:gozer:write_data/execute:deny
     1:user:gozer:read_data/write_data/execute:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

# mkdir test3.dir/subdir.1
# ls -dv test3.dir/subdir.1
drwxr-xr-x+  2 root     root           2 May 20 15:59 test3.dir/subdir.1
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :file_inherit/dir_inherit/inherit_only:allow
     1:user:gozer:add_file/write_data:deny
     2:user:gozer:list_directory/read_data/add_file/write_data/execute:allow
     3:owner@::deny
     4:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     5:group@:add_file/write_data/add_subdirectory/append_data:deny
     6:group@:list_directory/read_data/execute:allow
     7:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     8:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Dans ces exemples, les permission du répertoire parent pour group@ et everyone@ n'accordent pas les permissions d'écriture et d'exécution. Par conséquent, l'utilisateur gozer se voit refuser ces permissions. La propriété par défaut aclinherit est de restricted, ce qui signifie que les permissions write_data et execute ne sont pas héritées.

Dans l'exemple suivant, l'utilisateur gozer se voit accorder les permissions de lecture, d'écriture et d'exécution héritées des fichiers récemment créés. Toutefois, elles ne sont pas propagées vers le contenu subséquent du répertoire.

# chmod A+user:gozer:read_data/write_data/execute:file_inherit/no_propagate:allow 
test4.dir
# ls -dv test4.dir
drwxr-xr-x+  2 root     root           2 May 20 16:02 test4.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :file_inherit/no_propagate:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Comme l'exemple suivant l'illustre, lors de la création d'un sous-répertoire, la permission read_data/write_data/execute de l'utilisateur gozer pour les fichiers n'est pas propagée au nouveau répertoire sub4.dir :

mkdir test4.dir/sub4.dir
# ls -dv test4.dir/sub4.dir
drwxr-xr-x   2 root     root           2 May 20 16:03 test4.dir/sub4.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Comme l'exemple suivant l'illustre, les permissions read_data/write_data/execute de l'utilisateurgozer pour les fichiers sont propagées vers le nouveau fichier :

# touch test4.dir/file.4
# ls -v test4.dir/file.4
-rw-r--r--+  1 root     root           0 May 20 16:04 test4.dir/file.4
     0:user:gozer:write_data/execute:deny
     1:user:gozer:read_data/write_data/execute:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Exemple 8–7 Héritage d'ACL avec la propriété `aclmode` définie sur `passthrough`

Comme le montre l'exemple suivant, lorsque la propriété aclmode du système de fichiers tank/cindys est définie sur passthrough , l'utilisateur gozer hérite de l'ACL appliquée au répertoire test4.dir du fichier file.4 récemment créé :

# zfs set aclmode=passthrough tank/cindys
# touch test4.dir/file.4
# ls -v test4.dir/file.4
-rw-r--r--+  1 root     root           0 May 20 16:08 test4.dir/file.4
     0:user:gozer:write_data/execute:deny
     1:user:gozer:read_data/write_data/execute:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Cette sortie indique que l'ACL read_data/write_data/execute:allow:file_inherit/dir_inherit définie sur le répertoire parent, test4.dir, est transmise à l'utilisateur gozer.

Exemple 8–8 Héritage d'ACL avec la propriété `aclmode` définie sur `discard`

Si la propriété aclmode d'un système de fichiers est définie sur discard, il est alors possible de supprimer les ACL en cas de modification des permissions dans un répertoire. Exemple :

# zfs set aclmode=discard tank/cindys
# chmod A+user:gozer:read_data/write_data/execute:dir_inherit:allow test5.dir
# ls -dv test5.dir
drwxr-xr-x+  2 root     root           2 May 20 16:09 test5.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :dir_inherit:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Si vous décidez par la suite de renforcer les permissions d'un répertoire, l'ACL non triviale est supprimée. Exemple :

# chmod 744 test5.dir
# ls -dv test5.dir
drwxr--r--   2 root     root           2 May 20 16:09 test5.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data/execute:deny
     3:group@:list_directory/read_data:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /execute/write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/read_attributes/read_acl
         /synchronize:allow

Exemple 8–9 Héritage d'ACL avec la propriété `aclinherit` définie sur `noallow`

Dans l'exemple suivant, deux ACL non triviales avec héritage de fichier sont définies. Une ACL autorise le droit read_data, tandis qu'un autre refuse ce droit. L'exemple suivant montre également comment spécifier deux ACE dans la même commande chmod.

# zfs set aclinherit=noallow tank/cindys
# chmod A+user:gozer:read_data:file_inherit:deny,user:lp:read_data:file_inherit:allow 
test6.dir
# ls -dv test6.dir
drwxr-xr-x+  2 root     root           2 May 20 16:11 test6.dir
     0:user:gozer:read_data:file_inherit:deny
     1:user:lp:read_data:file_inherit:allow
     2:owner@::deny
     3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     4:group@:add_file/write_data/add_subdirectory/append_data:deny
     5:group@:list_directory/read_data/execute:allow
     6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Comme l'illustre l'exemple suivant, lors de la création d'un nouveau fichier, l'ACL qui autorise le droit read_data est supprimée.

# touch test6.dir/file.6
# ls -v test6.dir/file.6
-rw-r--r--   1 root     root           0 May 20 16:13 test6.dir/file.6
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Configuration et affichage d'ACL dans des fichiers ZFS en format compact

Vous pouvez définir et afficher les droits relatifs aux fichiers ZFS en format compact utilisant 14 lettres uniques pour représenter les droits. Les lettres représentant les permissions compactes sont répertoriées dans le Tableau 8–2 et le Tableau 8–3.

Vous pouvez afficher les listes d'ACL compactes pour les fichiers et les répertoires à l'aide de la commande ls -V. Exemple :

# ls -V file.1
-rw-r--r--   1 root     root      206663 Jun 17 10:07 file.1
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Cette sortie d'ACL compacte est décrite comme suit :

owner@: Les permissions d'exécution sur le fichier est refusée au propriétaire (x= execute).
owner@: Le propriétaire peut lire ou modifier le contenu du fichier (rw=read_data/write_data, p=append_data). Il peut également modifier les attributs du fichier, tels que les horodatages, les attributs étendus et les ACL (A=write_xattr , W=write_attributes et C=write_acl). De plus, le propriétaire peut modifier la propriété du fichier (o=write_owner).
group@: Les droits de modification et d'exécution sur le fichier sont refusés au groupe (write_data, p=append_data et x=execute).
group@: Les permissions de lecture sur le fichier sont accordées au groupe (r= read_data).
everyone@: Les permissions d'exécution ou de modification du contenu du fichier, ou de modification de tout attribut du fichier sont refusés à toute personne n'étant ni son propriétaire ni membre du groupe propriétaire du (w= write_data, x=execute, p =append_data, A=write_xattr , W=write_attributes, C= write_acl et o=write_owner).
everyone@: Toute personne n'étant pas le propriétaire du fichier ou membre du groupe propriétaire du fichier ne peut ni lire, ni synchroniser le fichier et ses attributs (r= read_data, a=append_data, R=read_xattr, c=read_acl et s=synchronize). Le droit d'accès synchronize n'est actuellement pas implémenté.

Le format d'ACL compact dispose deses avantages suivants par rapport au format détaillé :

Les droits peuvent être spécifiés en tant qu'arguments de position pour la commande chmod.
Les traits d'union (-) permettant d'identifier l'absence de permission peuvent être supprimés. Seules les lettres nécessaires doivent être spécifiées.
Les indicateurs de droits et d'héritage sont configurés de la même manière.

Pour obtenir des informations sur l'utilisation du format d'ACL détaillé, consultez Configuration et affichage d'ACL dans des fichiers ZFS en format détaillé.

Exemple 8–10 Configuration et affichage des ACL en format compact

Dans l'exemple suivant, une ACL triviale existe dans le fichier file.1 :

# ls -V file.1
-rw-r--r--   1 root     root      206663 Jun 17 10:07 file.1
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Dans l'exemple suivant, les permissions read_data/execute sont ajoutées à l'utilisateur gozer dans le fichier .

# chmod A+user:gozer:rx:allow file.1
# ls -V file.1
-rw-r--r--+  1 root     root      206663 Jun 17 10:07 file.1
        user:gozer:r-x-----------:------:allow
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Une autre méthode d'ajout des mêmes permissions pour l'utilisateur gozer consiste à insérer une entrée d'ACL à un emplacement spécifique, par exemple 4. Ainsi, les ACL existantes aux emplacements 4–6 sont déplacées vers le bas. Exemple :

# chmod A4+user:gozer:rx:allow file.1
# ls -V file.1
-rw-r--r--+  1 root     root      206663 Jun 17 10:16 file.1
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
        user:gozer:r-x-----------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Dans l'exemple suivant, l'utilisateur gozer se voit accorder les droits de lecture, d'écriture et d'exécution hérités des fichiers et répertoires récemment créés.

# chmod A+user:gozer:rwx:fd:allow dir.2
# ls -dV dir.2
drwxr-xr-x+  2 root     root           2 Jun 17 10:19 dir.2
        user:gozer:rwx-----------:fd----:allow
            owner@:--------------:------:deny
            owner@:rwxp---A-W-Co-:------:allow
            group@:-w-p----------:------:deny
            group@:r-x-----------:------:allow
         everyone@:-w-p---A-W-Co-:------:deny
         everyone@:r-x---a-R-c--s:------:allow

Vous pouvez également couper et coller les droits et les indicateurs d'héritage à partir de la sortie ls -V en format chmod compact. Par exemple, pour dupliquer les permissions et les indicateurs d'héritage du répertoire dir.2 de l'utilisateur gozer vers le répertoire dir.2 de l'utilisateur cindys , copiez et collez les permissions et les indicateurs d'héritage (rwx-----------:fd----:allow) dans la commande chmod comme suit :

# chmod A+user:cindys:rwx-----------:fd----:allow dir.2
# ls -dV dir.2
drwxr-xr-x+  2 root     root           2 Jun 17 10:19 dir.2
       user:cindys:rwx-----------:fd----:allow
        user:gozer:rwx-----------:fd----:allow
            owner@:--------------:------:deny
            owner@:rwxp---A-W-Co-:------:allow
            group@:-w-p----------:------:deny
            group@:r-x-----------:------:allow
         everyone@:-w-p---A-W-Co-:------:deny
         everyone@:r-x---a-R-c--s:------:allow

Exemple 8–11 Héritage d'ACL avec la propriété `aclinherit` définie sur `passthrough`

Un système de fichiers dont la propriété aclinherit est définie sur passthrough hérite de toutes les entrées d'ACL pouvant être héritées, sans qu'aucune modification ne leur soit apportée. Lorsque cette propriété est définie sur passthrough, les fichiers sont créés avec des permissions déterminées par les ACE pouvant être héritées. Si aucune ACE pouvant être héritée n'affecte les permissions, celles-ci sont alors définies en fonction des permissions demandées à partir de l'application.

Les exemples suivants utilisent la syntaxe ACL compacte pour illustrer le processus d'héritage des permissions en définissant la propriété aclinherit sur passthrough .

Dans cet exemple, une ACL est définie sur le répertoire test1.dir pour forcer l'héritage. La syntaxe crée une entrée d'ACL owner@, group@ et everyone@ pour les fichiers nouvellement créés. Les répertoires nouvellement créés héritent d'une entrée d'ACL @owner, group@ et everyone@. En outre, les répertoires héritent de 6 autres ACE qui appliquent les ACE aux fichiers et répertoires nouvellement créés.

# zfs set aclinherit=passthrough tank/cindys
# pwd
/tank/cindys
# mkdir test1.dir

# chmod A=owner@:rwxpcCosRrWaAdD:fd:allow,group@:rwxp:fd:allow,everyone@::fd:allow 
test1.dir
# ls -Vd test1.dir
drwxrwx---+  2 root     root           2 Jun 17 10:37 test1.dir
            owner@:rwxpdDaARWcCos:fd----:allow
            group@:rwxp----------:fd----:allow
         everyone@:--------------:fd----:allow

Dans cet exemple, un fichier nouvellement créé hérite de l'ACL dont les fichiers nouvellement créés doivent hériter d'après ce qui a été spécifié.

# cd test1.dir
# touch file.1
# ls -V file.1
-rwxrwx---+  1 root     root           0 Jun 17 10:38 file.1
            owner@:rwxpdDaARWcCos:------:allow
            group@:rwxp----------:------:allow
         everyone@:--------------:------:allow

Dans cet exemple, un répertoire nouvellement créé hérite à la fois des ACE contrôlant l'accès à ce répertoire et des ACE à appliquer ultérieurement aux enfants de ce répertoire.

# mkdir subdir.1
# ls -dV subdir.1
drwxrwx---+  2 root     root           2 Jun 17 10:39 subdir.1
            owner@:rwxpdDaARWcCos:fdi---:allow
            owner@:rwxpdDaARWcCos:------:allow
            group@:rwxp----------:fdi---:allow
            group@:rwxp----------:------:allow
         everyone@:--------------:fdi---:allow
         everyone@:--------------:------:allow

Les entrées -di-- et f-i--- permettent d'appliquer l'héritage et ne sont pas prises en compte lors du contrôle d'accès. Dans cet exemple, un fichier est créé avec une ACL insignifiante dans un autre répertoire ne contenant pas d'ACE héritées.

# cd /tank/cindys
# mkdir test2.dir
# cd test2.dir
# touch file.2
# ls -V file.2
-rw-r--r--   1 root     root           0 Jun 17 10:40 file.2
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Exemple 8–12 Héritage d'ACL avec la propriété `aclinherit` définie sur `passthrough-x`

Lorsque la propriété aclinherit est définie sur passthrough-x , les fichiers sont créés avec la permission d'exécution (x) pour owner@, group@ ou everyone@, mais seulement si la permission d'exécution est définie dans le mode de création de fichier et dans une ACE héritable affectant ce mode.

L'exemple suivant explique comment hériter de la permission d'exécution en définissant la propriété aclinherit sur passthrough-x.

# zfs set aclinherit=passthrough-x tank/cindys

L'ACL suivante est définie sur /tank/cindys/test1.dir pour permettre l'héritages des ACL exécutables pour les fichiers de owner@, group@ et everyone@.

# chmod A=owner@:rwxpcCosRrWaAdD:fd:allow,group@:rwxp:fd:allow,everyone@::fd:allow test1.dir
# ls -Vd test1.dir
drwxrwx---+  2 root     root           2 Jun 17 10:41 test1.dir
            owner@:rwxpdDaARWcCos:fd----:allow
            group@:rwxp----------:fd----:allow
         everyone@:--------------:fd----:allow

Un fichier (file1) est créé avec les autorisations demandées 0666. Les autorisations obtenues sont 0660. L'autorisation d'exécution n'était pas héritée car le mode de création ne le requérait pas.

# touch test1.dir/file1
# ls -V test1.dir/file1
-rw-rw----+  1 root     root           0 Jun 17 10:42 test1.dir/file1
            owner@:rw-pdDaARWcCos:------:allow
            group@:rw-p----------:------:allow
         everyone@:--------------:------:allow

Ensuite, un fichier exécutable appelé t est généré à l'aide du compilateur cc dans le répertoire testdir.

# cc -o t t.c
# ls -V t
-rwxrwx---+  1 root     root        7396 Jun 17 10:50 t
                 owner@:rwxpdDaARWcCos:------:allow
                 group@:rwxp----------:------:allow
              everyone@:--------------:------:allow

Les autorisations obtenues sont 0770 car cc a demandé des autorisations 0777, ce qui a entraîné l'héritage de l'autorisation d'exécution à partir des entrées propriétaire@, groupe@ et tous les utilisateurs@.