Ignorer les liens de navigation | |
Quitter l'aperu | |
Administration d'Oracle Solaris 11.1 : Systèmes de fichiers ZFS Oracle Solaris 11.1 Information Library (Français) |
1. Système de fichiers Oracle Solaris ZFS (introduction)
2. Mise en route d'Oracle Solaris ZFS
3. Gestion des pools de stockage Oracle Solaris ZFS
4. Gestion des composants du pool root ZFS
5. Gestion des systèmes de fichiers Oracle Solaris ZFS
6. Utilisation des instantanés et des clones ZFS Oracle Solaris
7. Utilisation des ACL et des attributs pour protéger les fichiers Oracle Solaris ZFS
Configuration d'ACL dans des fichiers ZFS
Configuration et affichage d'ACL dans des fichiers ZFS en format détaillé
Configuration d'héritage d'ACL dans des fichiers ZFS en format détaillé
Configuration et affichage d'ACL dans des fichiers ZFS en format compact
Application d'attributs spéciaux aux fichiers ZFS
8. Administration déléguée de ZFS dans Oracle Solaris
9. Rubriques avancées Oracle Solaris ZFS
10. Dépannage d'Oracle Solaris ZFS et récupération de pool
11. Archivage des instantanés et récupération du pool root
12. Pratiques recommandées pour Oracle Solaris ZFS
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 7-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.
Deux formats d'ACL de base sont fournis comme suit :
ACL triviales – Contient uniquement des entrées user, group et owner UNIX traditionnelles.
ACL non triviale – Contient plus d'entrées qu'owner, group et everyone, inclut des indicateurs d'héritage ou les entrées sont triées d'une manière non traditionnelle.
Syntaxe pour la configuration d'ACL triviales
chmod [options] A[index]{+|=}owner@ |group@ |everyone@: autorisations d'accès/...[:indicateurs d'héritage]: deny | allow file
chmod [options] A-owner@, group@, everyone@:autorisations d'accès /...[:indicateurs d'héritage]:deny | allow file ...
chmod [options] A[index]- file
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 file
chmod [options] A-user|group:name:autorisations d'accès /...[:indicateurs d'héritage]:deny | allow file ...
chmod [options] A[index]- file
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 7-1.
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 7-1.
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 7-2.
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 7-4.
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 7-1 Types d'entrées d'ACL
|
Les privilèges d'accès sont décrits dans le tableau suivant.
Tableau 7-2 Privilèges d'accès d'ACL
|
Le tableau suivant fournit des détails supplémentaires sur les comportements delete et delete_child d'ACL.
Tableau 7-3 Comportement des autorisations delete et delete_child d'ACL.
|
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 :
|
Ces jeux d'ACL sont prédéfinis et ne peuvent pas être modifiés
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 7-4 Indicateurs d'héritage d'ACL
|
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 d'informations, consultez la section suivante.
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 7-14.