Nouveau modèle ACL Solaris

Les versions précédentes de Solaris assuraient la prise en charge d'une implémentation ACL reposant principalement sur la spécification POSIX-draft ACL. 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 différences principales du nouveau modèle d'ACL sont les suivantes :

Modèle basé sur la spécification NFSv4 et similaire aux ACL de type NT.
Jeu de privilèges d'accès bien plus granulaire. Pour plus d'informations, reportez-vous au Tableau 8-2.
Configuration et affichage avec les commandes chmod et ls, et non les commandes setfacl et getfacl.
Sémantique d'héritage bien plus riche pour déterminer comment les privilèges d'accès sont appliqués d'un répertoire à un sous-répertoire, et ainsi de suite. 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 à un niveau de granularité plus fin que celui disponible avec les autorisations 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 quelles autorisations sont accordées et lesquelles sont refusées. Le nouveau modèle d'ACL dispose de deux types d'ACE qui affectent la vérification d'accès : ALLOW et DENY. Il est en soi impossible de déduire de toute entrée de contrôle d'accès (ACE) définissant un groupe d'autorisations si les autorisations qui n'ont pas été définies dans cette ACE sont ou non accordées.

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.
Les ACL NFSv4 sont converties en ACL POSIX-draft. Un message tel que le suivant s'affiche si une ACL NFSv4 n'est pas convertie en ACL POSIX-draft :
```
# 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 incluent des ACL POSIX-style, elles sont converties en ACL NFSv4-style.
En cas de tentative de configuration d'une ACL SFSv4 dans un fichier UFS, un message tel que le suivant s'affiche :
```
chmod: ERROR: ACL type's are different
```

En cas de tentative de configuration d'une ACL POSIX dans un fichier ZFS, un message tel que le suivant s'affiche :

# 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

Deux formats d'ACL de base sont fournis comme suit :

Syntaxe pour la configuration d'ACL triviales

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

chmod [options] A-owner@, group@, everyone@:autorisations 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:autorisations d'accès /...[:indicateurs d'héritage]:deny | allow fichier

chmod [options] A-user|group:name:autorisations 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ées d'ACL, reportez-vous au Tableau 8-1.
utilisateur ou groupe :ID-entrée-ACL=nomutilisateur ou nomgroupe: Identifie le type d'entrée d'ACL pour la syntaxe d'ACL explicite. Le type d'entrée d'ACL pour l'utilisateur et le groupe doit également contenir l'ID d'entrée d'ACL, le nom d'utilisateur ou le nom de groupe. Pour obtenir une description des types d'entrées d'ACL, reportez-vous au Tableau 8-1.
autorisations-d'accès/.../: Identifie les autorisations d'accès accordées ou refusées. 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-4.
deny | allow: Détermine si les autorisations d'accès sont accordées ou refusées.

Dans l'exemple suivant, aucune valeur d'ID d'entrée d'ACL n'existe pour owner@, group@ ou everyone@.

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

La désignation 2 ou ID d'index dans cet exemple identifie l'entrée d'ACL dans la plus grande ACL, qui peut présenter plusieurs entrées pour le propriétaire, des UID spécifiques, un groupe 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 d'index 3 par A3 dans la commande chmod comme ci-dessous :

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. Doit inclure l'ID d'entrée d'ACL qui contient un `nom d'utilisateur` ou un `ID 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. Doit inclure l'ID d'entrée d'ACL qui contient 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`	Autorisation d'ajouter un fichier à un répertoire.
`add_subdirectory`	`p`	Dans un répertoire, autorisation de créer un sous-répertoire.
`append_data`	`p`	Non implémentée actuellement.
`delete`	`d`	Droit de supprimer un fichier. Pour plus d'informations sur le comportement spécifique de l'autorisation `delete`, reportez-vous au Tableau 8-3.
`delete_child`	`D`	Droit de supprimer un fichier ou un répertoire au sein d'un répertoire. Pour plus d'informations sur le comportement spécifique de l'autorisation `delete_child` , reportez-vous au Tableau 8-3.
`execute`	`x`	Autorisation d'exécuter un fichier ou d'effectuer une recherche dans le contenu d'un répertoire.
`list_directory`	`r`	Autorisation de dresser la liste du contenu d'un répertoire.
`read_acl`	`c`	Autorisation de lire l'ACL (`ls`).
`read_attributes`	a	Autorisation 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`	Autorisation de lire le contenu du fichier.
`read_xattr`	`R`	Autorisation de lire les attributs étendus d'un fichier ou d'effectuer une recherche dans le répertoire d'attributs étendus d'un fichier.
`synchronize`	`s`	Non implémentée actuellement.
`write_xattr`	`W`	Autorisation de créer des attributs étendus ou d'écrire dans le répertoire d'attributs étendus. L'attribution de cette autorisation à un utilisateur signifie que ce dernier peut créer un répertoire d'attributs étendus pour un fichier. Les autorisations du fichier d'attributs contrôlent l'accès de l'utilisateur à l'attribut.
`write_data`	`w`	Autorisation de modifier ou de remplacer le contenu d'un fichier.
`write_attributes`	`A`	Autorisation de remplacer les durées associées à un fichier ou un répertoire par une valeur arbitraire.
`write_acl`	`C`	Autorisation d'écriture sur l'ACL ou capacité de la modifier à l'aide de la commande `chmod`.
`write_owner`	`o`	Autorisation de modifier le propriétaire ou le groupe d'un fichier. Ou capacité d'exécuter les commandes `chown` ou `chgrp` sur le fichier. Autorisation de devenir propriétaire d'un fichier ou autorisation 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.

Le tableau suivant fournit des détails supplémentaires sur les comportements delete et delete_child d'ACL.

Tableau 8-3 Comportement des autorisations delete et delete_child d'ACL.

Droits d'accès au répertoire parent	Autorisations d'objet cible
	L'ACL autorise la suppression	L'ACL refuse la suppression	Autorisation de suppression non spécifiée
L'ACL autorise `delete_child`	Autorisation	Autorisation	Autorisation
L'ACL refuse `delete_child`	Autorisation	Refus	Refus
L'ACL autorise uniquement `write` et `execute`	Autorisation	Autorisation	Autorisation
L'ACL refuse `write` et `execute`	Autorisation	Refus	Refus

Jeux d'ACL ZFS

Au lieu de définir séparément des autorisations individuelles, il est possible d'appliquer les combinaisons d'ACL suivantes par le biais d'un jeu d'ACL. Les jeux d'ACL suivants sont disponibles :

Nom de jeu d'ACL	Autorisations d'ACL incluses
`full_set`	Toutes les autorisations
`modify_set`	Toutes les autorisations à l'exception de `write_acl` et `write_owner`
`read_set`	`read_data`, `read_attributes`, `read_xattr` et `read_acl`
`write_set`	`write_data`, `append_data`, `write_attributes` et `write_xattr`

Ces jeux d'ACL sont prédéfinis et ne peuvent pas être modifiés

Héritage d'ACL

L'héritage d'ACL a pour finalité de permettre à un fichier ou répertoire récemment créé d'hériter des ACL qui leur sont destinées, tout en tenant compte des bits d'autorisation existants dans le répertoire parent.

Par défaut, les ACL ne sont pas propagées. Si vous configurez une ACL non triviale dans un répertoire, aucun répertoire enfant n'en hérite. 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-4 Indicateurs d'héritage d'ACL

Indicateur d'héritage	Indicateur d'héritage compact	Description
`file_inherit`	`f`	Hérite de l'ACL uniquement à partir du répertoire parent vers les fichiers du répertoire.
`dir_inherit`	`d`	Hérite de l'ACL uniquement à partir du répertoire parent vers les 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	Aucune autorisation n'est accordée.
Actuellement, les indicateurs suivants s'appliquent uniquement à un client ou serveur SMB.
`successful_access`	`S`	Indique si une alarme ou un enregistrement d'audit doit être initié lorsqu'un accès réussit. Cet indicateur est utilisé avec les types d'ACE (entrées de contrôle d'accès) d'audit ou d'alarme.
`failed_access`	`F`	Indique si une alarme ou un enregistrement d'audit doit être lancé lorsqu'un accès échoue. Cet indicateur est utilisé avec les types d'ACE (entrées de contrôle d'accès) d'audit ou d'alarme.
`inherited`	`I`	Indique qu'une ACE a été héritée.

De plus, vous pouvez configurer une stratégie d'héritage d'ACL par défaut plus ou moins stricte 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

Le système de fichiers ZFS inclut les propriétés d'ACL suivantes permettant de déterminer le comportement spécifique de l'héritage d'ACL et des interactions d'ACL avec les opérations chmod.

aclinherit : détermine le comportement d'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 fichier ou le répertoire est égale au mode d'autorisation 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 autorisations write_owner et write_acl sont supprimées lorsqu'une entrée d'ACL est héritée.
- passthrough : lorsqu'une valeur de propriété est définie sur passthrough, les fichiers sont créés dans un mode déterminé par les ACE héritées. Si aucune ACE pouvant être héritée n'affecte le mode, ce mode est alors défini en fonction du mode demandé à partir de l'application.
- passthrough-x : a la même sémantique que passthrough, si ce n'est que lorsque passthrough-x est activé, les fichiers sont créés avec l'autorisation d'exécution (x), mais uniquement si l'autorisation d'exécution est définie en mode de création de fichier et dans une entrée de contrôle d'accès (ACE) pouvant être héritée et qui affecte le mode.
Le mode par défaut de aclinherit est restricted.
aclmode : modifie le comportement des ACL lorsqu'un fichier est créé et contrôle la modification des ACL au cours d'une opération chmod. Les valeurs possibles sont les suivantes :
- discard :un système de fichiers dont la valeur de la propriété aclmode est discard supprime toutes les entrées d'ACL qui ne représentent pas le mode du fichier. Il s'agit de la valeur par défaut.
- mask : un système de fichiers dont la valeur de la propriété aclmode est mask restreint les autorisations utilisateur ou groupe. Les autorisations sont réduites de manière à ne pas excéder les bits d'autorisation du groupe, à moins qu'il ne s'agisse d'une entrée utilisateur possédant le même UID que le propriétaire du fichier ou du répertoire. Dans ce cas, les autorisations d'ACL sont réduites de manière à ne pas excéder les bits d'autorisation du propriétaire. La valeur de masque préserve en outre l'ACL lors des modifications de mode successives, à condition qu'aucune opération de jeu d'ACL explicite n'ait été effectuée.
- passthrough : un système de fichiers avec une propriété aclmode de passthrough indique qu'aucune modification n'est apportée à l'ACL en dehors de la génération des entrées d'ACL nécessaires pour représenter le nouveau mode du fichier ou du répertoire.
Le mode par défaut pour aclmode est discard.

Pour plus d'informations sur l'utilisation de la propriété aclmode, reportez-vous à l'Exemple 8-14.

Ignorer les liens de navigation
Quitter l'aperu
	Administration d'Oracle Solaris : Systèmes de fichiers ZFS Oracle Solaris 11 Information Library (Français)