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
Descriptions de syntaxe pour la configuration des ACL
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
Dans la mesure où elles sont implémentées avec ZFS, les ACL se composent d'un tableau d'entrées d'ACL. ZFS fournit un modèle d'ACL pur, dans lequel tous les fichiers présentent une ACL. En règle générale, cette liste est triviale dans la mesure où elle ne représente que les entrées propriétaire/groupe/autre UNIX classiques.
Les fichiers ZFS disposent toujours de bits d'autorisation et d'un mode, mais ces valeurs constituent plutôt un cache de ce que représente une ACL. Par conséquent, si vous modifiez les autorisations du fichier, son ACL 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 d'autorisation qui accordent l'accès à un groupe ou à tous les utilisateurs. L'ensemble des décisions de contrôle d'accès est régi par les autorisations représentées dans l'ACL d'un fichier ou d'un répertoire.
Les règles principales d'accès aux ACL dans un fichier ZFS sont comme suit :
ZFS traite les entrées d'ACL dans l'ordre dans lesquelles elles sont répertoriées dans l'ACL, en partant du haut.
Seules les entrées d'ACL disposant d'un " who " correspondant au demandeur d'accès sont traitées.
Une fois l'autorisation allow accordée, cette dernière ne peut plus être refusée par la suite par une entrée d'ACL de refus dans le même jeu de d'autorisations d'ACL.
Le propriétaire du fichier dispose de l'autorisation write_acl de façon inconditionnelle, même si celle-ci est explicitement refusée. Dans le cas contraire, toute autorisation non spécifiée est refusée.
Dans les cas d'autorisations deny ou lorsqu'une autorisation d'accès est manquante, le sous-système de privilèges détermine la demande 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 puissent 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, reportez-vous au Tableau 7-4 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 Jun 23 15:06 file.1 0:owner@:read_data/write_data/append_data/read_xattr/write_xattr /read_attributes/write_attributes/read_acl/write_acl/write_owner /synchronize:allow 1:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow 2:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow
Chaque catégorie d'utilisateur (owner@, group@, everyone@) dispose d'une entrée d'ACL dans cet exemple.
Voici une description de l'ACL de ce fichier :
Le propriétaire peut lire et modifier le contenu du fichier (read_data/write_data/append_data). Il 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).
L'autorisation d'accès synchronize n'est actuellement pas implémentée.
Les autorisations de lecture du fichier et de ses attributs sont attribuées au groupe (read_data/read_xattr/read_attributes/read_acl:allow).
Les autorisations de lecture du fichier et de ses attributs sont attribués à toute personne ne correspondant ni à un utilisateur ni à un groupe (read_data/read_xattr/read_attributes/read_acl/synchronize:allow ). L'autorisation d'accès synchronize n'est actuellement pas implémentée.
Lorsqu'un répertoire est créé, en fonction de la valeur umask, l'ACL par défaut du répertoire est similaire à l'exemple suivant :
$ ls -dv dir.1 drwxr-xr-x 2 root root 2 Jul 20 13:44 dir.1 0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory /append_data/read_xattr/write_xattr/execute/delete_child /read_attributes/write_attributes/read_acl/write_acl/write_owner /synchronize:allow 1:group@:list_directory/read_data/read_xattr/execute/read_attributes /read_acl/synchronize:allow 2:everyone@:list_directory/read_data/read_xattr/execute/read_attributes /read_acl/synchronize:allow
Voici une description de l'ACL de ce répertoire :
Le propriétaire peut lire et modifier le contenu du répertoire (list_directory/read_data/add_file/write_data/add_subdirectory/append_data ) et lire et modifier les attributs du fichier tels que les horodatages, les attributs étendus et les ACL (/read_xattr/write_xattr/read_attributes/write_attributes/read_acl/write_acl ). En outre, le propriétaire peut faire des recherches dans le contenu (execute), supprimer un fichier ou un répertoire (delete_child) et modifier la possession du répertoire (write_owner:allow).
L'autorisation d'accès synchronize n'est actuellement pas implémentée.
Le groupe peut répertorier et lire le contenu et les attributs du répertoire. De plus, le groupe dispose d'autorisations d'exécution pour effectuer des recherches dans le contenu du répertoire (list_directory/read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow).
Toute personne n'étant ni un utilisateur ni un groupe dispose d'autorisations de lecture et d'exécution sur le contenu et les attributs du répertoire (list_directory/read_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow ). L'autorisation d'accès synchronize n'est actuellement pas implémentée.