Utilisation d'ACL pour protéger les fichiers Sun QFS et SAM-QFS

Les versions précédentes d'Oracle Solaris assuraient une prise en charge des ACL reposant principalement sur la spécification 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 Oracle Solaris 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ée sur des ACL NT.

Les principales nouveautés introduites par le nouveau modèle ACL sont les suivantes :

Basé sur la spécification NFSv4 et similaire aux ACL de type NT.
Jeu de privilèges d'accès plus détaillé. Pour plus d'informations, reportez-vous au Tableau 8-3.
Définition et affichage exécutés à l'aide des commandes chmod et ls, au lieu des commandes setfacl et getfacl.
Sémantique héritée plus riche pour définir l'application des privilèges d'accès. Pour plus d'informations, reportez-vous à la section Héritage d'ACL.

Les deux modèles ACL fournissent un contrôle d'accès bien plus fin que celui permis par les autorisations de fichier standard. A l'instar des listes ACL POSIX-draft, les nouvelles ACL se composent de plusieurs ACE (Access Control Entry, entrées de contrôle d'accès).

Les ACL de type POSIX-draft se basent sur une seule entrée pour définir quelles autorisations seront acceptées ou 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. 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 d'autorisations si les autorisations qui n'ont pas été définies dans cette ACE sont ou non autorisées.

Pour plus d'informations sur le nouveau modèle ACL Oracle Solaris, reportez-vous à la section New Solaris ACL Model du manuel Oracle Solaris Administration: ZFS File Systems.

Mise en correspondance des identités d'utilisateur et de groupe dans SAM-QFS

Actuellement, SAM-QFS ne prend en charge ni les ID ni les SID éphémères. Par conséquent, toutes les identités Windows doivent être explicitement définies à l'aide du service idmap ou doivent être fournies par le service Active Directory. Les identités rencontrées par le serveur SMB pour lesquelles aucun mappage explicite n'est défini prendront par défaut l'identité nobody.

Pour plus d'informations sur l'administration du mappage d'identités, reportez-vous au Chapitre 2, Identity Mapping Administration (Tasks) du manuel Oracle Solaris Administration: SMB and Windows Interoperability.

Création et conversion des systèmes de fichiers pour prendre en charge les ACL NFSv4

Les ACL POSIX sont les ACL par défaut présentes dans les systèmes de fichiers SAM-QFS. Afin d'assurer la prise en charge du service SMB, les systèmes de fichiers SAM-QFS doivent également prendre en charge les ACL NFSv4.

Exécutez la commande sammkfs -A pour créer un système de fichiers avec des ACL NFSv4. Par exemple, pour créer un système de fichiers appelé sqfs1 avec des ACL NFSv4, exécutez la ligne suivante :
```
# sammkfs -A -S sqfs1
```
Pour plus d'informations sur l'option -A dans la commande sammkfs, reportez-vous à la section sammkfs(1M) du manuel Sun QFS and Sun Storage Archive Manager 5.3 Reference Manual .
Exécutez la commande samfsck -A pour convertir des ACL POSIX existantes en listes NFSv4. Par exemple, pour convertir des ACL POSIX en listes NFSv4 sur un système de fichiers existant appelé sqfs2, exécutez la ligne suivante :
```
# samfsck -F -A sqfs2 
```
Remarque - La conversion des listes ACL POSIX en listes NFSv4 est irréversible. La conversion s'applique uniquement aux versions V2 ou V2A des système de fichiers.

Pour plus d'informations sur l'utilisation de l'option -A avec la commande samfsck, reportez-vous à la section samfsck(1M) du manuel Sun QFS and Sun Storage Archive Manager 5.3 Reference Manual.

Description de la syntaxe utilisée pour configurer les ACL

Les deux formats ACL de base sont les suivants :

Syntaxe utilisée pour configurer des 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 utilisée pour configurer des 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

owner@, group@, everyone@: Identifie le type d'entrée d'ACL pour la syntaxe ACL triviale. Pour obtenir une description des types d'entrée d'ACL, reportez-vous au Tableau 8-2.
user ou group : ID d'entrée d'ACL=username ou groupname: Identifie le type d'entrée d'ACL pour la syntaxe ACL explicite. Les types d'entrée d'ACL user et group doivent également contenir les éléments suivants : ID d'entrée d'ACL, nom d'utilisateur ou nom du groupe. Pour obtenir une description des types d'entrée d'ACL, reportez-vous au Tableau 8-2.
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-3.
indicateurs d'héritage: Identifie une liste optionnelle d'indicateurs d'héritage d'ACL. Pour obtenir 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, 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-2 Type d'entrée 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 d'ACL, qui contient un `username` ou un `user-ID`. Le type d'entrée d'ACL est incorrect si la valeur n'est ni un UID numérique, ni un `username` valide.
`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 d'ACL, contenant un `groupname` ou un `group-ID`. Le type d'entrée d'ACL est incorrect si la valeur n'est ni un GID numérique, ni un `groupname` valide.

Les privilèges d'accès sont décrits dans le tableau suivant.

Tableau 8-3 Privilèges d'accès d'ACL

Privilège d'accès	Description
`add_file`	Autorisation d'ajouter un fichier à un répertoire.
`add_subdirectory`	Dans un répertoire, autorisation de créer un sous-répertoire.
`delete`	Autorisation de supprimer un fichier.
`delete_child`	Autorisation de supprimer un fichier ou un répertoire au sein d'un répertoire.
`execute`	Autorisation permettant d'exécuter un fichier ou d'effectuer une recherche dans le contenu d'un répertoire.
`list_directory`	Autorisation de dresser la liste du contenu d'un répertoire.
`read_acl`	Autorisation de lire l'ACL (`ls`).
`read_attributes`	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`	Autorisation de lire le contenu d'un fichier.
`read_xattr`	Autorisation de lire les attributs étendus d'un fichier ou d'effectuer une recherche dans le répertoire d'attributs étendus d'un fichier.
`write_xattr`	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`	Autorisation de modifier ou de remplacer le contenu d'un fichier.
`write_attributes`	Autorisation de remplacer les horodatages associés à fichier ou un répertoire par une valeur arbitraire.
`write_acl`	Autorisation d'écriture sur l'ACL ou de modification de celle-ci à l'aide de la commande `chmod`.
`write_owner`	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 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.

Exemple 8-3 Modification des ACL triviales dans les fichiers SAM-QFS

Dans l'exemple suivant, une ACL triviale existe dans le fichier file.1 :

# ls -v file.1
-rw-r--r--   1 root     root      206674 Jun 14 10:54 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

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 autorisations existantes 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-4 Indicateurs d'héritage d'ACL

Indicateur d'héritage	Description
`file_inherit`	Hérite de l'ACL à partir du répertoire parent mais s'applique uniquement aux fichiers du répertoire.
`dir_inherit`	Hérite de l'ACL à partir du répertoire parent mais s'applique uniquement aux sous-répertoires du répertoire.
`inherit_only`	Hérite de l'ACL à partir du répertoire parent. 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'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é.

Par défaut, les ACL ne sont pas propagées dans l'ensemble d'une structure de répertoires.

Exemple 8-4 Octroi de l'héritage d'ACL par défaut

Dans l'exemple suivant, une ACE non triviale des privilèges read_data/write_data/execute s'applique pour l'utilisateur gozer sur test.dir.

# chmod A+user:gozer:read_data/write_data/execute:allow test.dir
# ls -dv test.dir
drwxr-xr-x+  2 root     root           2 Jun 15 10:40 test.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute:allow
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/read_attributes
         /write_attributes/read_acl/write_acl/write_owner/synchronize:allow
     2:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     3:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Si un sous-répertoire est créé dans test.dir, l'ACE de l'utilisateur gozer n'est pas propagée. L'utilisateur gozer aurait uniquement accès au répertoire sub.dir si les autorisations appliquées à ce répertoire lui permettaient d'y accéder en tant que propriétaire de fichier, membre du groupe ou everyone@.

# mkdir test.dir/sub.dir
# ls -dv test.dir/sub.dir
drwxr-xr-x   2 root     root           2 Jun 15 10:41 test.dir/sub.dir
     0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/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

Exemple 8-5 Octroi de l'héritage d'ACL sur des fichiers compris dans des répertoires

Dans l'exemple suivant, certaines autorisations s'appliquent à tous les fichiers nouvellement créés dans un répertoire, mais pas au répertoire lui-même. L'indicateur file_inherit indique que les autorisations sont destinées aux fichiers et l'indicateur inherit_only indique qu'il s'agit d'autorisations "héritées" qui ne s'appliqueront pas au répertoire lui-même.

# chmod A+user:bob:read_data/execute:file_inherit/inherit_only:deny mydir
# ls -vd mydir
dr-xr-xr-x+     2     root     root        4096 Jul 5 19:10 mydir 
   0:user:bob:list_directory/read_data/execute:file_inherit/inherit_only:deny
   1: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
   2:group@:list_directory/read_data/read_xattr/execute/read_attributes
      /read_acl/synchronize:allow
   3:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
      /read_acl/synchronize:allow

Si un fichier myfile est créé dans le répertoire mydir , le fichier myfile hérite automatiquement de toutes les autorisations d'accès.

# cd mydir
# touch myfile
# ls -v myfile
-r--r--r--+     1     root     root        0 Jul 5 19:11 myfile

   0:user:bob:read_data/execute:file_inherit/inherit_only:deny
   1:owner@:read_data/write_data/append_data/read_xattr/write_xattr
      /read_attributes/write_attributes/read_acl/write_acl/write_owner
      /synchronize:allow
   2:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
   3:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow

Ignorer les liens de navigation
Quitter l'aperu
	Guide de configuration et d'administration du système de fichiers Sun QFS 5.3 Sun QFS and Sun Storage Archive Manager 5.3 Information Library (Français)