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 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 droits autorisés 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. Il est en soi impossible de déduire de toute entrée de contrôle d'accès (ACE) 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.
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 :

Syntax for Setting Trivial ACLs

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é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.
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, 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	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.
exécution	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 le contenu du fichier.
read_xattr	R	Droit de lire les attributs étendus d'un fichier ou d'effectuer une recherche dans le répertoire d'attributs étendus d'un fichier.
synchroniser	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 durées associées à un fichier ou un répertoire par une valeur arbitraire.
write_acl	C	Droit d'écriture sur l'ACL ou capacité de la modifier à 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 récemment créé d'hériter des ACL qui leurs sont destinées, tout en tenant compte des bits de droits 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-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 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	Aucun droit n'est accordé.

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 plus amples d'informations, consultez la section suivante.

Propriété ACL (`aclinherit`)

Le système de fichiers ZFS comprend la propriété aclinherit permettant de déterminer 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 fichier ou le répertoire est égale au mode de droit 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 – 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.

Ignorer les liens de navigation
Quitter l'aperu
	Guide d'administration Oracle Solaris ZFS