Guide d'administration Oracle Solaris ZFS

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 .