Comprendre les listes de contrôle d'accès NFSv4.x dans Azure NetApp Files

Article
02/17/2024

Le protocole NFSv4.x peut fournir un contrôle d'accès sous la forme de listes de contrôle d'accès (ACL), conceptuellement similaires aux ACL utilisées dans SMB via les autorisations Windows NTFS. Une ACL NFSv4.x se compose d'entrées de Microsoft Azure Access Control Service (ACE) individuelles, chacune fournissant une directive de contrôle d'accès au serveur.

Chaque ACL NFSv4.x est créée au format de type:flags:principal:permissions.

Type – le type d’ACL en cours de définition. Les choix valides incluent Accès (A), Refuser (D), Audit (U), Alarme (L). Azure NetApp Files prend en charge les types d'ACL d'accès, de refus et d'audit, mais les ACL d'audit, bien qu'elles puissent être définies, ne produisent actuellement pas de journaux d'audit.
Drapeaux – ajoute un contexte supplémentaire pour une ACL. Il existe trois types d’indicateurs ACE : groupe, héritage et administratif. Pour plus d'informations sur les indicateurs, consultez Indicateurs NFSv4.x ACE.
Principal – définit l'utilisateur ou le groupe auquel l'ACL est attribuée. Un principal sur une ACL NFSv4.x utilise le format de name@ID-DOMAIN-STRING.COM. Pour des informations plus détaillées sur les mandataires, consultez Principaux d'utilisateur et de groupe NFSv4.x.
Autorisations – où le niveau d'accès du principal est défini. Chaque autorisation est désignée par une seule lettre (par exemple, lire obtient « r », écrire obtient « w », etc.). L'accès complet incorporerait chaque lettre d'autorisation disponible. Pour plus d'informations, consultez Autorisations NFSv4.x.

A:g:group1@contoso.com:rwatTnNcCy est un exemple d'ACL valide, suivant le format type:flags:principal:permissions. L’exemple d’ACL accorde un accès complet au groupe group1 dans le domaine ID contoso.com.

Indicateurs ACE NFSv4.x

Un indicateur ACE permet de fournir plus d’informations sur une ACE dans une ACL. Par exemple, si un groupe ACE est ajouté à une ACL, un indicateur de groupe doit être utilisé pour désigner le principal comme un groupe et non un utilisateur. Il est possible dans les environnements Linux d'avoir un nom d'utilisateur et un nom de groupe identiques, donc l'indicateur garantit qu'un ACE est honoré, le serveur NFS doit alors savoir quel type de principal est défini.

D’autres indicateurs peuvent être utilisés pour contrôler les ACE, tels que les indicateurs d’héritage et d’administration.

Accéder et refuser les indicateurs

Les indicateurs d’accès (A) et de refus (D) sont utilisés pour contrôler les types ACE de sécurité. Une ACE d'accès contrôle le niveau d'autorisations d'accès sur un fichier ou un dossier pour un principal. Une ACE de refus interdit explicitement à un mandataire d'accéder à un fichier ou à un dossier, même si une ACE d'accès est définie pour permettre à ce mandataire d'accéder à l'objet. Les ACE de refus annulent toujours les ACE d’accès. En général, évitez d'utiliser les ACE de refus, car les ACL NFSv4.x suivent un modèle de « refus par défaut », ce qui signifie que si une ACL n'est pas ajoutée, le refus est implicite. Refuser les ACE peut créer des complications inutiles dans la gestion des ACL.

Drapeaux d'héritage

Les indicateurs d'héritage contrôlent le comportement des ACL sur les fichiers créés sous un répertoire parent avec l'indicateur d'héritage défini. Lorsqu'un indicateur d'héritage est défini, les fichiers et/ou répertoires héritent des ACL du dossier parent. Les indicateurs d'héritage ne peuvent être appliqués qu'aux répertoires, donc lorsqu'un sous-répertoire est créé, il hérite de l'indicateur. Les fichiers créés sous un répertoire parent avec un indicateur d'héritage héritent des ACL, mais pas des indicateurs d'héritage.

Le tableau suivant décrit les indicateurs d'héritage disponibles et leurs comportements.

Drapeau d'héritage	Comportement
j	– Les répertoires situés sous le répertoire parent héritent de l'ACL – L'indicateur d'héritage est également hérité
f	– Les fichiers situés sous le répertoire parent héritent de l'ACL – Les fichiers ne définissent pas l'indicateur d'héritage
i	Héritage uniquement ; L'ACL ne s'applique pas au répertoire actuel mais doit appliquer l'héritage aux objets situés sous le répertoire
n	– Pas de propagation de l'héritage Une fois l'ACL héritée, les indicateurs d'héritage sont effacés sur les objets situés sous le parent

Exemples d'ACL NFSv4.x

Dans l’exemple suivant, il existe trois ACE différentes avec des indicateurs d’héritage distincts :

répertoire hériter uniquement (di)
fichier hériter uniquement (fi)
le fichier et le répertoire héritent (fdi)

# nfs4_getfacl acl-dir

# file: acl-dir/
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdi:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

User1 a un répertoire qui hérite uniquement de l'ACL. Sur un sous-répertoire créé sous le parent, l'ACL est héritée, mais sur un fichier situé sous le parent, elle ne l'est pas.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file 
                       << ACL missing
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User2 a un indicateur d'héritage de fichier et de répertoire. Par conséquent, les fichiers et les répertoires situés sous un répertoire contenant cette entrée ACE héritent de l’ACL, mais les fichiers n’hériteront pas de l’indicateur.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy << no flag
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User3 n'a qu'un indicateur d'héritage de fichier. Par conséquent, seuls les fichiers situés sous le répertoire avec cette entrée ACE héritent de l’ACL, mais ils n’héritent pas de l’indicateur car il ne peut être appliqué qu’aux ACE de répertoire.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy << no flag
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

Lorsqu'un indicateur « no-propogate » (n) est défini sur une liste de contrôle d'accès, les indicateurs s'effacent lors des créations ultérieures de répertoires sous le parent. Dans l’exemple suivant, l’indicateur user2 est défini comme n. Par conséquent, le sous-répertoire efface les indicateurs d'héritage pour ce principal et les objets créés sous ce sous-répertoire n'héritent pas de l'ACE de user2.

#  nfs4_getfacl /mnt/acl-dir

# file: /mnt/acl-dir
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdn:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

#  nfs4_getfacl inherit-dir/

# file: inherit-dir/
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A::user2@CONTOSO.COM:rwaDxtTnNcCy << flag cleared
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# mkdir subdir
# nfs4_getfacl subdir

# file: subdir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
<< ACL not inherited
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

Les indicateurs d'héritage sont un moyen de gérer plus facilement vos ACL NFSv4.x, vous évitant ainsi de définir explicitement une ACL à chaque fois que vous en avez besoin.

Drapeaux administratifs

Les indicateurs d'administration dans les ACL NFSv4.x sont des indicateurs spéciaux qui sont utilisés uniquement avec les types d'ACL Audit et Alarme. Ces indicateurs définissent les tentatives d'accès réussies (S) ou échouées (F) pour les actions à effectuer.

Azure NetApp Files prend en charge la définition d’indicateurs administratifs pour les ACE d’audit, mais les ACE ne fonctionnent pas. De plus, les ACE d’alarme ne sont pas prises en charge dans Azure NetApp Files.

Principaux d'utilisateur et de groupe NFSv4.x

Avec les ACL NFSv4.x, les principaux utilisateurs et groupes définissent les objets spécifiques auxquels une ACE doit s'appliquer. Les directeurs suivent généralement un format de name@ID-DOMAIN-STRING.COM. La partie « nom » d'un mandataire peut être un utilisateur ou un groupe, mais cet utilisateur ou ce groupe doit pouvoir être résolu dans Azure NetApp Files via la connexion au serveur LDAP lors de la spécification du domaine d'ID NFSv4.x. Si le nom@domaine ne peut pas être résolu par Azure NetApp Files, l’opération ACL échoue avec une erreur « argument non valide ».

# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument

Vous pouvez vérifier dans Azure NetApp Files si un nom peut être résolu à l’aide de la liste d’ID de groupe LDAP. Accédez à Support + Dépannage, puis à la liste des ID de groupe LDAP.

Accès des utilisateurs et groupes locaux via les ACL NFSv4.x

Les utilisateurs et groupes locaux peuvent également être utilisés sur une ACL NFSv4.x si seul l'ID numérique est spécifié dans l'ACL. Les noms d'utilisateur ou les ID numériques avec un ID de domaine spécifié échouent.

Exemple :

# nfs4_setfacl -a A:fdg:3003:rwaxtTnNcCy NFSACL
# nfs4_getfacl NFSACL/
A:fdg:3003:rwaxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rwaDxtTnNcy
A::EVERYONE@:rwaDxtTnNcy

# nfs4_setfacl -a A:fdg:3003@CONTOSO.COM:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

# nfs4_setfacl -a A:fdg:users:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

Lorsqu'une ACL d'utilisateur ou de groupe local est définie, tout utilisateur ou groupe correspondant à l'ID numérique sur l'ACL reçoit l'accès à l'objet. Pour les ACL de groupe local, un utilisateur transmet ses appartenances à un groupe à Azure NetApp Files. Si l’ID numérique du groupe ayant accès au fichier via la requête de l’utilisateur est affiché sur le serveur NFS Azure NetApp Files, l’accès est autorisé conformément à l’ACL.

Les informations d'identification transmises du client au serveur peuvent être vues via une capture de paquet comme indiqué ci-dessous.

Avertissements :

L'utilisation d'utilisateurs et de groupes locaux pour les ACL signifie que chaque client accédant aux fichiers/dossiers doit avoir des ID d'utilisateur et de groupe correspondants.
Lors de l’utilisation d’un ID numérique pour une liste de contrôle d’accès, Azure NetApp Files s’assure implicitement que la requête entrante est valide et que l’utilisateur demandant l’accès est celui qu’il prétend être et qu’il est membre des groupes dont il prétend être membre. Un utilisateur ou un groupe numérique peut être usurpé si un acteur malveillant connaît l'ID numérique et peut accéder au réseau à l'aide d'un client ayant la possibilité de créer des utilisateurs et des groupes localement.
Si un utilisateur est membre de plus de 16 groupes, tout groupe après le seizième groupe (par ordre alphanumérique) se voit refuser l'accès au fichier ou au dossier, à moins que la prise en charge LDAP et des groupes étendus ne soit utilisée.
Les chaînes LDAP et nom complet @ nom de domaine sont fortement recommandées lors de l'utilisation des ACL NFSv4.x pour une meilleure gestion et sécurité. Un référentiel d'utilisateurs et de groupes géré de manière centralisée est plus facile à maintenir et plus difficile à usurper, ce qui rend moins probable l'accès des utilisateurs indésirables.

Domaine d'identification NFSv4.x

Le domaine ID est un composant important du principal, où un domaine ID doit correspondre à la fois sur le client et dans Azure NetApp Files pour que les noms d'utilisateur et de groupe (en particulier, racine) s'affichent correctement sur les propriétés des fichiers/dossiers.

Azure NetApp Files définit par défaut le domaine d'ID NFSv4.x sur les paramètres de domaine DNS du volume. Les clients NFS utilisent également par défaut le domaine DNS pour le domaine d'ID NFSv4.x. Si le domaine DNS du client est différent du domaine DNS Azure NetApp Files, une incompatibilité se produit. Lors de la liste des autorisations de fichiers avec des commandes telles que ls, les utilisateurs/groupes apparaissent comme « personne ».

Lorsqu’une incompatibilité de domaine se produit entre le client NFS et Azure NetApp Files, recherchez dans les journaux du client des erreurs similaires à celles-ci :

August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'

Le domaine d'ID du client NFS peut être remplacé à l'aide du paramètre « Domaine » du fichier /etc/idmapd.conf. Par exemple : Domain = CONTOSO.COM.

Azure NetApp Files vous permet également de modifier le domaine d'ID NFSv4.1. Pour plus de détails, consultez Comment : configuration de domaine d'ID NFSv4.1 pour Azure NetApp Files.

Autorisations NFSv4.x

Les autorisations NFSv4.x permettent de contrôler le niveau d'accès d'un utilisateur ou d'un principal de groupe spécifique à un fichier ou un dossier. Les autorisations dans NFSv3 autorisent uniquement les niveaux de définition d'accès en lecture/écriture/exécution (rwx), mais NFSv4.x fournit une multitude d'autres contrôles d'accès granulaires en guise d'amélioration par rapport aux bits du mode NFSv3.

Il existe 13 autorisations pouvant être définies pour les utilisateurs et 14 autorisations pouvant être définies pour les groupes.

Lettre d’autorisation	Autorisation accordée
r	Lire les fichiers et dossiers de données/listes
w	Écrire des données/créer des fichiers et des dossiers
a	Ajouter des données/créer des sous-répertoires
x	Exécuter des fichiers/parcourir des répertoires
j	Supprimer des fichiers/répertoires
D	Supprimer des sous-répertoires (répertoires uniquement)
t	Attributs de lecture (GETATTR)
T	Attributs d’écriture (SETATTR/chmod)
n	Lire les attributs nommés
N	Écrire des attributs nommés
c	Lire les ACL
C	Écrire des ACL
o	Écrire le propriétaire (chown)
y	E/S synchrone

Lorsque les autorisations d'accès sont définies, un utilisateur ou un groupe principal adhère à ces droits attribués.

Exemples d'autorisations NFSv4.x

Les exemples suivants montrent comment différentes autorisations fonctionnent avec différents scénarios de configuration.

Utilisateur avec accès en lecture (r uniquement)

Avec un accès en lecture seule, un utilisateur peut lire des attributs et des données, mais tout accès en écriture (données, attributs, propriétaire) est refusé.

A::user1@CONTOSO.COM:r

sh-4.2$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Jul 12 12:41 .
drwxr-xr-x 3 root root 4096 Jul 12 12:09 ..
-rw-r--r-- 1 root root    0 Jul 12 12:41 file
drwxr-xr-x 2 root root 4096 Jul 12 12:31 subdir
sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ chown user1 file
chown: changing ownership of ‘file’: Operation not permitted
sh-4.2$ nfs4_setfacl -e /mnt/acl-dir/inherit-dir
Failed setxattr operation: Permission denied
sh-4.2$ rm file
rm: remove write-protected regular empty file ‘file’? y
rm: can't remove ‘file’: Permission denied
sh-4.2$ cat file
Test text

Utilisateur avec accès en lecture (r) et attributs d'écriture (T)

Dans cet exemple, les autorisations sur le fichier peuvent être modifiées en raison de l'autorisation des attributs d'écriture (T), mais aucun fichier ne peut être créé puisque seul l'accès en lecture est autorisé. Cette configuration illustre le type de contrôles granulaires que les ACL NFSv4.x peuvent fournir.

A::user1@CONTOSO.COM:rT

sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:23 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
-rw-r--r--  1 root     root      10 Jul 12 16:22 file
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rw-r--r--  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ chmod 777 user1-file
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:41 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rwxrwxrwx  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ rm user1-file
rm: can't remove ‘user1-file’: Permission denied

Traduction des bits de mode en autorisations ACL NFSv4.x

Lorsqu'un chmod est exécuté sur un objet avec des ACL NFSv4.x attribuées, une série d'ACL système est mise à jour avec de nouvelles autorisations. Par exemple, si les autorisations sont définies sur 755, les fichiers ACL du système sont mis à jour. Le tableau suivant montre ce que chaque valeur numérique d'un bit de mode se traduit dans les autorisations ACL NFSv4.

Voir Autorisations NFSv4.x pour un tableau décrivant toutes les autorisations.

Bit de mode numérique	Autorisations NFSv4.x correspondantes
1 – exécuter (x)	Exécuter, lire les attributs, lire les ACL, synchroniser les E/S (xtcy)
2 – écrire (w)	Écrire, ajouter des données, lire des attributs, écrire des attributs, écrire des attributs nommés, lire des ACL, synchroniser les E/S (watTNcy)
3 – écrire/exécuter (wx)	Écrire, ajouter des données, exécuter, lire des attributs, écrire des attributs, écrire des attributs nommés, lire des ACL, synchroniser les E/S (waxtTNcy)
4 – lire (r)	Lire, lire les attributs, lire les attributs nommés, lire les ACL, synchroniser les E/S (rtncy)
5 – lire/exécuter (rx)	Lire, exécuter, lire les attributs, lire les attributs nommés, lire les ACL, synchroniser les E/S (rxtncy)
6 – lire/écrire (rw)	Lire, écrire, ajouter des données, lire des attributs, écrire des attributs, lire des attributs nommés, écrire des attributs nommés, lire des ACL, synchroniser les E/S (rwatTnNcy)
7 – lire/écrire/exécuter (rwx)	Contrôle total/toutes les autorisations

Fonctionnement des ACL NFSv4.x avec Azure NetApp Files

Azure NetApp Files prend en charge les ACL NFSv4.x de manière native lorsque NFSv4.1 est activé pour l'accès à un volume. Il n'y a rien à activer sur le volume pour la prise en charge des ACL, mais pour que les ACL NFSv4.1 fonctionnent mieux, un serveur LDAP avec des utilisateurs et des groupes UNIX est nécessaire pour garantir qu'Azure NetApp Files est capable de résoudre les principaux définis sur les ACL. en toute sécurité. Les utilisateurs locaux peuvent être utilisés avec les ACL NFSv4.x, mais ils n'offrent pas le même niveau de sécurité que les ACL utilisées avec un serveur LDAP.

Il y a des considérations à garder à l’esprit concernant la fonctionnalité ACL dans Azure NetApp Files.

Héritage des listes de contrôle d'accès

Dans Azure NetApp Files, les indicateurs d’héritage ACL peuvent être utilisés pour simplifier la gestion des ACL avec les ACL NFSv4.x. Lorsqu'un indicateur d'héritage est défini, les ACL d'un répertoire parent peuvent se propager aux sous-répertoires et aux fichiers sans autre interaction. Azure NetApp Files implémente les comportements d'héritage d'ACL standard conformément à la RFC-7530.

ACE Refuser

Les ACE de refus dans Azure NetApp Files sont utilisées pour empêcher explicitement un utilisateur ou un groupe d’accéder à un fichier ou un dossier. Un sous-ensemble d’autorisations peut être défini pour fournir des contrôles granulaires sur l’ACE de refus. Ceux-ci fonctionnent selon les méthodes standard mentionnées dans la RFC-7530.

Préservation des ACL

Lorsqu'un chmod est effectué sur un fichier ou un dossier dans Azure NetApp Files, toutes les ACE existantes sont conservées sur l'ACL autres que les ACE système (OWNER@, GROUP@, EVERYONE@). Ces autorisations ACE sont modifiées comme défini par les bits de mode numérique définis par la commande chmod. Seuls les ACE modifiés ou supprimés manuellement via la commande nfs4_setfacl peuvent être modifiés.

Comportements d'ACL NFSv4.x dans les environnements à double protocole

Le double protocole fait référence à l’utilisation de SMB et NFS sur le même volume Azure NetApp Files. Les contrôles d'accès à double protocole sont déterminés par le style de sécurité utilisé par le volume, mais le mappage des noms d'utilisateur garantit que les utilisateurs Windows et les utilisateurs UNIX qui sont mappés avec succès disposent des mêmes autorisations d'accès aux données.

Lorsque les ACL NFSv4.x sont utilisées sur des volumes de style de sécurité UNIX, les comportements suivants peuvent être observés lors de l'utilisation de volumes à double protocole et de l'accès aux données des clients SMB.

Les noms d'utilisateur Windows doivent être correctement mappés aux noms d'utilisateur UNIX pour une résolution appropriée du contrôle d'accès.
Dans les volumes de style de sécurité UNIX (où les ACL NFSv4.x seraient appliquées), s'il n'existe aucun utilisateur UNIX valide sur le serveur LDAP pour un utilisateur Windows vers lequel mapper, alors un utilisateur UNIX par défaut appelé pcuser (avec l'uid numérique 65534) est utilisé pour le mappage. .
Les fichiers écrits avec des utilisateurs Windows sans mappage d'utilisateur UNIX valide s'affichent comme appartenant à l'ID numérique 65534, ce qui correspond aux noms d'utilisateur « nfsnobody » ou « nobody » dans les clients Linux à partir de montages NFS. Ceci est différent de l'ID numérique 99 qui est généralement observé avec les problèmes de domaine d'ID NFSv4.x. Pour vérifier l'ID numérique utilisé, utilisez la commande ls -lan.
Les fichiers avec des propriétaires incorrects ne fournissent pas les résultats attendus des bits du mode UNIX ou des ACL NFSv4.x.
Les ACL NFSv4.x sont gérées à partir des clients NFS. Les clients SMB ne peuvent ni afficher ni gérer les ACL NFSv4.x.

Impact d'Umask avec les ACL NFSv4.x

Les ACL NFSv4 offrent la possibilité d'offrir l'héritage d'ACL. L'héritage ACL signifie que les fichiers ou dossiers créés sous des objets avec des ACL NFSv4 définies peuvent hériter des ACL en fonction de la configuration de l'indicateur d'héritage ACL.

Umask est utilisé pour contrôler le niveau d'autorisation auquel les fichiers et dossiers sont créés dans un répertoire. Par défaut, Azure NetApp Files permet à umask de remplacer les ACL héritées, ce qui est un comportement attendu selon RFC-7530.

Pour plus d’informations, consultez umask.

Comportement Chmod/chown avec les ACL NFSv4.x

Dans Azure NetApp Files, vous pouvez utiliser les commandes de changement de propriétaire (chown) et de changement de mode (chmod) pour gérer les autorisations de fichiers et de répertoires sur NFSv3 et NFSv4.x.

Lors de l'utilisation des ACL NFSv4.x, les contrôles plus granulaires appliqués aux fichiers et aux dossiers réduisent le besoin de commandes chmod. Chown a toujours sa place, car les ACL NFSv4.x n'attribuent pas de propriété.

Lorsque chmod est exécuté dans Azure NetApp Files sur des fichiers et des dossiers avec des ACL NFSv4.x appliquées, les bits de mode sont modifiés sur l'objet. De plus, un ensemble d'ACE système est modifié pour refléter ces bits de mode. Si les ACE système sont supprimés, les bits de mode sont effacés. Des exemples et une description plus complète peuvent être trouvés dans la section sur les ACE système ci-dessous.

Lorsque chown est exécuté dans Azure NetApp Files, le propriétaire attribué peut être modifié. La propriété des fichiers n'est pas aussi critique lors de l'utilisation des ACL NFSv4.x que lors de l'utilisation des bits de mode, car les ACL peuvent être utilisées pour contrôler les autorisations d'une manière que les concepts de base de propriétaire/groupe/tout le monde ne pourraient pas. Chown dans Azure NetApp Files ne peut être exécuté qu'en tant qu'utilisateur root (soit en tant qu'utilisateur root, soit en utilisant sudo), car les contrôles d'exportation sont configurés pour permettre uniquement à l'utilisateur root d'effectuer des modifications de propriété. Étant donné que cela est contrôlé par une règle de stratégie d’exportation par défaut dans Azure NetApp Files, les entrées d’ACL NFSv4.x qui autorisent les modifications de propriété ne s’appliquent pas.

# su user1
# chown user1 testdir
chown: changing ownership of ‘testdir’: Operation not permitted
# sudo chown user1 testdir
# ls -la | grep testdir
-rw-r--r--  1 user1    root     0 Jul 12 16:23 testdir

La règle de politique d'exportation sur le volume peut être modifiée pour changer ce comportement. Dans le menu Stratégie d'exportation du volume, modifiez le mode Chown sur « sans restriction ».

Une fois modifiée, la propriété peut être modifiée par des utilisateurs autres que root s'ils disposent des droits d'accès appropriés. Cela nécessite l’autorisation ACL NFSv4.x « Take Ownership » (désignée par la lettre « o »). La propriété peut également être modifiée si l'utilisateur qui change de propriété est actuellement propriétaire du fichier ou du dossier.

A::user1@contoso.com:rwatTnNcCy  << no ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
chown: changing ownership of 'newfile3': Permission denied

A::user1@contoso.com:rwatTnNcCoy  << with ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
user1@ubuntu:/mnt/testdir$ ls -la
total 8
drwxrwxrwx 2 user2 root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root  root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1 root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root  root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 user1 4294967294    0 Jul 14 16:31 newfile3

ACE système

Sur chaque ACL, il existe une série d'ACE système : OWNER@, GROUP@, EVERYONE@. Par exemple :

A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

Ces ACE correspondent aux autorisations de bits en mode classique que vous verriez dans NFSv3 et sont directement associées à ces autorisations. Lorsqu'un chmod est exécuté sur un objet, ces ACL système changent pour refléter ces autorisations.

# nfs4_getfacl user1-file

# file: user1-file
A::user1@CONTOSO.COM:rT
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

# chmod 755 user1-file

# nfs4_getfacl user1-file

# file: user1-file
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rxtncy

Si ces ACE système sont supprimés, la vue des autorisations change de telle sorte que les bits du mode normal (rwx) apparaissent sous forme de tirets.

# nfs4_setfacl -x A::OWNER@:rwaxtTnNcCy user1-file
# nfs4_setfacl -x A:g:GROUP@:rxtncy user1-file
# nfs4_setfacl -x A::EVERYONE@:rxtncy user1-file
# ls -la | grep user1-file
----------  1 user1 group1     0 Jul 12 16:23 user1-file

La suppression des ACE système est un moyen de sécuriser davantage les fichiers et les dossiers, car seuls les principaux utilisateurs et groupes sur l'ACL (et la racine) peuvent accéder à l'objet. La suppression des ACE système peut interrompre les applications qui dépendent des vues de bits de mode pour la fonctionnalité.

Comportement de l'utilisateur root avec les ACL NFSv4.x

L'accès root avec les ACL NFSv4.x ne peut pas être limité à moins que la racine ne soit écrasée. L'écrasement de racine est l'endroit où une règle de politique d'exportation est configurée où la racine est mappée à un utilisateur anonyme pour limiter l'accès. L'accès racine peut être configuré à partir du menu de Stratégie d'exportation d'un volume en désactivant la règle de politique d'Accès racine.

Pour configurer l'écrasement racine, accédez au menu de Stratégie d'exportation sur le volume, puis modifiez « Accès racine » sur « désactivé » pour la règle de stratégie.

L'effet de la désactivation des écrasements root de l'accès root pour un utilisateur anonyme nfsnobody:65534. L'accès root est alors incapable de changer de propriétaire.

root@ubuntu:/mnt/testdir# touch newfile3
root@ubuntu:/mnt/testdir# ls -la
total 8
drwxrwxrwx 2 user2  root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root   root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1  root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root   root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 nobody 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# ls -lan
total 8
drwxrwxrwx 2  1002          0 4096 Jul 14 16:31 .
drwxrwxrwx 5     0          0 4096 Jul 13 13:46 ..
-rw-r--r-- 1  1001          0    0 Jul 14 15:45 newfile
-rw-r--r-- 1     0          0    0 Jul 14 15:52 newfile2
-rw-r--r-- 1 65534 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# chown root newfile3
chown: changing ownership of 'newfile3': Operation not permitted

Alternativement, dans les environnements à double protocole, les ACL NTFS peuvent être utilisées pour limiter de manière granulaire l'accès root.

Partager via