Les autorisations bits du mode couvrent uniquement le propriétaire, le groupe et tous les autres éléments de la sémantique, ce qui signifie qu'aucun contrôle granulaire des accès utilisateur n'est mis en place pour les données NFSv3 de base. Cloud Volumes Service ne prend pas en charge les listes de contrôle d'accès POSIX, ni les attributs étendus (tels que chattr). Les listes de contrôle d'accès granulaires ne sont donc possibles que dans les scénarios suivants avec NFSv3 :

Ces deux méthodes nécessitent une connexion LDAP pour la gestion des identités UNIX et des informations utilisateur et groupe UNIX valides (voir la section "« LDAP »") Et ne sont disponibles qu'avec des instances CVS-Performance. Pour utiliser des volumes de style de sécurité NTFS avec le protocole NFS, vous devez utiliser le protocole double (SMB et NFS v3) ou le double protocole (SMB et NFS v4.1), même si aucune connexion SMB n'est établie. Pour utiliser les listes de contrôle d'accès NFSv4.1 avec montages NFSv3, vous devez sélectionner Both (NFSv3/NFSv4.1) comme type de protocole.

Les bits standard en mode UNIX ne fournissent pas le même niveau de granularité dans les autorisations que les ACL NTFS ou NFSv4.x fournissent. Le tableau suivant compare la granularité des autorisations entre les bits en mode NFS v3 et les ACL NFSv4.1. Pour plus d'informations sur les listes de contrôle d'accès NFSv4.1, voir "Nfs4_acl - listes de contrôle d'accès NFSv4".

Enfin, l'appartenance au groupe NFS (dans NFSv3 et NFSV4.x) est limitée à un maximum par défaut de 16 pour AUTH_SYS selon les limites de paquets RPC. NFS Kerberos fournit jusqu'à 32 groupes et les ACL NFSv4 suppriment la limite par le biais de listes de contrôle d'accès granulaires des utilisateurs et des groupes (jusqu'à 1024 entrées par ACE).

En outre, Cloud Volumes Service offre une prise en charge étendue des groupes pour étendre le nombre maximal de groupes pris en charge jusqu'à 32. Pour ce faire, une connexion LDAP à un serveur LDAP qui contient des identités d'utilisateur et de groupe UNIX valides est nécessaire. Pour plus d'informations sur cette configuration, reportez-vous à la section "Création et gestion des volumes NFS" Dans la documentation Google.

Avec NFSv3, le client et le serveur n'ont jamais à confirmer que l'utilisateur qui tente de lire ou d'écrire avec un ID numérique est un utilisateur valide ; il est simplement implicitement approuvé. Cela ouvre le système de fichiers jusqu'à des failles potentielles simplement en usurper n'importe quel ID numérique. Pour éviter les trous de sécurité de ce type, il existe quelques options pour Cloud Volumes Service.

En fin de compte, la sécurité NFS est limitée à la version de protocole que vous utilisez. NFS v3, bien que plus performant que NFSv4.1, n'offre pas le même niveau de sécurité.

En raison des fonctions de sécurité ajoutées dans NFSv4.1, certaines dépendances externes étaient impliquées dans l'utilisation de NFSv3 (semblable au mode d'utilisation requis par SMB, comme Active Directory).

Cloud Volumes Service prend en charge les listes de contrôle d'accès NFSv4.x, qui offrent des avantages distincts par rapport aux autorisations de style POSIX standard, notamment :

Les ACL NFSv4 ne sont pas plus les ACL de niveau fichier (ACL NTFS) de Windows, mais possèdent une fonctionnalité similaire. Cependant, dans les environnements NAS multiprotocoles, si vous disposez de listes de contrôle d'accès NFSv4.1 et que vous utilisez un accès double protocole (NFS et SMB sur les mêmes datasets), les clients qui utilisent SMB2.0 et versions ultérieures ne pourront pas afficher ni gérer les listes de contrôle d'accès à partir des onglets de sécurité Windows.

Pour référence, les termes suivants sont définis :

Lorsqu'un client définit une liste de contrôle d'accès NFSv4.1 sur un fichier lors d'une opération SETATTR, Cloud Volumes Service définit cette liste de contrôle d'accès sur l'objet en remplaçant toute liste de contrôle d'accès existante. S'il n'y a pas de liste de contrôle d'accès sur un fichier, les autorisations de mode sur ce fichier sont calculées à partir DE OWNER@, GROUP@ et EVERYONE@. S'il existe des SUID/SGID/bits COLLANTS sur le fichier, ils ne sont pas affectés.

Lorsqu'un client obtient une liste de contrôle d'accès NFS (ACL) NFSv4.1 sur un fichier au cours d'une opération GETATTR, Cloud Volumes Service lit la liste de contrôle d'accès NFS (ACL) associée à l'objet, construit une liste d'ACE et renvoie la liste au client. Si le fichier possède une liste de contrôle d’accès NT ou des bits de mode, une liste de contrôle d’accès est construite à partir de bits de mode et renvoyée au client.

L'accès est refusé si une ACE DE REFUS est présente dans la liste de contrôle d'accès ; l'accès est accordé si une ACE D'AUTORISATION existe. Toutefois, l'accès est également refusé si aucun des ACE n'est présent dans l'ACL.

Un descripteur de sécurité se compose d'une liste de contrôle d'accès (SACL) et d'une liste de contrôle d'accès discrétionnaire (DACL). Lorsque NFSv4.1 interagit avec CIFS/SMB, le DACL est mappé à NFSv4 et CIFS. La DACL se compose des ACCE AUTORISER et REFUSER.

Si un niveau de base chmod Est exécuté sur un fichier ou un dossier avec les ACL NFSv4.1 définies, les listes de contrôle d'accès utilisateur et groupe existantes sont conservées, mais le PROPRIÉTAIRE par défaut@, GROUPE@, EVERYONE@ ACL sont modifiés.

Un client utilisant des listes de contrôle d’accès NFSv4.1 peut définir et afficher des listes de contrôle d’accès pour les fichiers et les répertoires du système. Lorsqu'un nouveau fichier ou sous-répertoire est créé dans un répertoire comportant une liste de contrôle d'accès, cet objet hérite de tous les ACE de la liste de contrôle d'accès qui ont été marqués avec le nom approprié "indicateurs d'héritage".

Si un fichier ou un répertoire possède une liste de contrôle d'accès NFSv4.1, cette liste de contrôle d'accès est utilisée pour contrôler l'accès, quel que soit le protocole utilisé pour accéder au fichier ou au répertoire.

Les fichiers et les répertoires héritent des ACE des listes de contrôle d'accès NFSv4 sur les répertoires parents (éventuellement avec les modifications appropriées) tant que les ACE ont été balisés avec les indicateurs d'héritage corrects.

Lorsqu'un fichier ou un répertoire est créé à la suite d'une requête NFSv4, la liste de contrôle d'accès du fichier ou répertoire résultant dépend du fait que la demande de création de fichier inclut une liste de contrôle d'accès ou uniquement les autorisations d'accès aux fichiers UNIX standard. La liste de contrôle d’accès dépend également de la présence ou non d’une liste de contrôle d’accès dans le répertoire parent.

Les autorisations de listes de contrôle d'accès NFSv4.1 utilisent une série de valeurs de lettres majuscules et minuscules (par exemple rxtncy) pour contrôler l'accès. Pour plus d'informations sur ces valeurs de lettre, reportez-vous à la section "COMMENT : utiliser NFSv4 ACL".

"Les ACL NFSv4 permettent d'offrir l'héritage ACL". L'héritage ACL signifie que les fichiers ou les dossiers créés sous des objets avec des listes de contrôle d'accès NFSv4.1 peuvent hériter des listes de contrôle d'accès basées sur la configuration du "Indicateur d'héritage ACL".

"Umask" permet de contrôler le niveau d'autorisation auquel les fichiers et dossiers sont créés dans un répertoire sans interaction avec l'administrateur. Par défaut, Cloud Volumes Service permet à umask de remplacer les listes de contrôle d'accès héritées, ce qui est le comportement attendu selon "RFC 5661".

Les ACL NFSv4.1 ont un formatage spécifique. L'exemple suivant est un ensemble ACE sur un fichier :

L'exemple précédent suit les directives de format ACL de :

Un type de A signifie « autoriser ». Les indicateurs hériter ne sont pas définis dans ce cas, car le principal n'est pas un groupe et n'inclut pas l'héritage. De plus, comme l'ACE n'est pas une entrée D'AUDIT, il n'est pas nécessaire de définir les indicateurs d'audit. Pour plus d'informations sur les listes de contrôle d'accès NFSv4.1, voir "http://linux.die.net/man/5/nfs4_acl".

Si la liste de contrôle d’accès NFSv4.1 n’est pas définie correctement (ou si une chaîne de nom ne peut pas être résolue par le client et le serveur), la liste de contrôle d’accès peut ne pas se comporter comme prévu, ou si la modification de la liste de contrôle d’accès échoue à s’appliquer et générer une erreur.

Les exemples d'erreurs sont les suivants :

Les autorisations NFSv4.1 peuvent inclure des attributs DE REFUS explicites pour LE PROPRIÉTAIRE, LE GROUPE et TOUT LE MONDE. En effet, les listes de contrôle d’accès NFSv4.1 étant des listes de contrôle d’accès par défaut, ce qui signifie que si une liste de contrôle d’accès n’est pas explicitement accordée par une ACE, elle est alors refusée. Les attributs DE REFUS explicite remplacent les ACE D'ACCÈS, explicites ou non.

LES ACE DE REFUS sont définis avec une balise d'attribut de D.

Dans l'exemple ci-dessous, GROUP@ est autorisé à toutes les autorisations de lecture et d'exécution, mais a refusé tout accès en écriture.

DANS la mesure du possible, LES ACE DE REFUS doivent être évités parce qu'ils peuvent être confus et compliqués ; AUTORISER les listes de contrôle d'accès qui ne sont pas explicitement définies sont refusées implicitement. Lorsque LES ACE DE REFUS sont définis, les utilisateurs peuvent se voir refuser l'accès lorsqu'ils s'attendent à bénéficier de l'accès.

L'ensemble précédent d'ACE est équivalent à 755 bits de mode, ce qui signifie :

Cependant, même si les autorisations sont ajustées à l'équivalent 775, l'accès peut être refusé en raison du REFUS explicite défini sur TOUT LE MONDE.

NFSv4.1 s'appuie sur la logique de mappage de domaine d'ID en tant que couche de sécurité pour garantir qu'un utilisateur qui tente d'accéder à un montage NFSv4.1 est en effet celui qu'il prétend être. Dans ce cas, le nom d'utilisateur et le nom de groupe provenant du client NFSv4.1 ajoute une chaîne de nom et l'envoie à l'instance Cloud Volumes Service. Si cette combinaison nom d'utilisateur/groupe et chaîne ID ne correspond pas, alors l'utilisateur et/ou le groupe est écrasé par défaut, aucun utilisateur spécifié dans le /etc/idmapd.conf fichier sur le client.

Cette chaîne d'ID est une exigence pour le respect correct des autorisations, en particulier lorsque des ACL NFSv4.1 et/ou Kerberos sont utilisés. Par conséquent, des dépendances au niveau du serveur de service de noms, telles que les serveurs LDAP, sont nécessaires pour assurer la cohérence entre les clients et Cloud Volumes Service afin de permettre une résolution appropriée de l'identité des noms d'utilisateur et de groupe.

Cloud Volumes Service utilise une valeur de nom de domaine d'ID par défaut statique de defaultv4iddomain.com. Les clients NFS utilisent par défaut le nom de domaine DNS pour ses paramètres de nom de domaine ID, mais vous pouvez régler manuellement le nom de domaine ID dans /etc/idmapd.conf.

Si le protocole LDAP est activé dans Cloud Volumes Service, Cloud Volumes Service automatise le domaine d'ID NFS pour modifier ce qui est configuré pour le domaine de recherche dans DNS et les clients n'ont pas besoin d'être modifiés à moins qu'ils n'utilisent des noms de recherche de domaine DNS différents.

Lorsque Cloud Volumes Service peut résoudre un nom d'utilisateur ou un nom de groupe dans les fichiers locaux ou LDAP, la chaîne de domaine est utilisée et les ID de domaine ne sont pas identiques. Si Cloud Volumes Service ne parvient pas à trouver un nom d'utilisateur ou un nom de groupe dans les fichiers locaux ou LDAP, la valeur d'ID numérique est utilisée et le client NFS résout correctement le nom (ceci est similaire au comportement NFSv3).

Sans modifier le domaine d'ID NFSv4.1 du client pour correspondre à l'utilisation du volume Cloud Volumes Service, le comportement suivant s'affiche :

Voici les résultats du scénario précédent :

Lorsque les domaines d'ID client et serveur correspondent, voici l'apparence de la même liste de fichiers :

Pour plus d'informations sur ce problème et sur la façon de le résoudre, reportez-vous à la section «NFSv4.1 et personne utilisateur/groupe. »

Si vous prévoyez d'utiliser Kerberos avec NFS, vous devez disposer des éléments suivants en Cloud Volumes Service :

L'un des problèmes les plus courants rencontrés avec une configuration NFSv4.1 est lorsqu'un fichier ou un dossier est affiché dans une liste à l'aide de ls appartenant au user:group combinaison de nobody:nobody.

Par exemple :

Et l'ID numérique est 99.

Dans certains cas, le fichier peut indiquer le propriétaire correct, mais nobody en tant que groupe.

Qui n'est personne?

Le nobody L'utilisateur dans NFSv4.1 est différent de nfsnobody utilisateur. Vous pouvez afficher la manière dont un client NFS voit chaque utilisateur en exécutant le id commande :

Avec NFSv4.1, le nobody l'utilisateur est l'utilisateur par défaut défini par le idmapd.conf et peut être défini comme n'importe quel utilisateur que vous voulez utiliser.

Pourquoi cela se produit-il ?

Étant donné que la sécurité par mappage de chaînes de noms est un principe clé des opérations NFSv4.1, le comportement par défaut lorsqu'une chaîne de noms ne correspond pas correctement est de court-courser cet utilisateur à un utilisateur qui n'aura normalement pas accès aux fichiers et dossiers appartenant aux utilisateurs et aux groupes.

Lorsque vous voyez nobody Pour l'utilisateur et/ou le groupe dans les listes de fichiers, cela signifie généralement que quelque chose dans NFSv4.1 est mal configuré. La sensibilité de la casse peut être ici en jeu.

Par exemple, si utilisateur1@CVSDEMO.LOmabL (uid 1234, gid 1234) accède à une exportation, alors Cloud Volumes Service doit pouvoir trouver utilisateur1@CVSDEMO.LOMOL (uid 1234, gid 1234). Si l'utilisateur dans Cloud Volumes Service est USER1@CVSDEMO.LOmabmacop, il ne correspond pas (majuscules UTILISATEUR1 contre minuscules utilisateur1). Dans de nombreux cas, vous pouvez voir ce qui suit dans le fichier de messages sur le client :

Le client et le serveur doivent tous deux convenir qu'un utilisateur est effectivement celui qu'il prétend être. Vous devez donc vérifier les éléments suivants pour vous assurer que l'utilisateur que le client voit dispose des mêmes informations que l'utilisateur que celui que Cloud Volumes Service voit.

Dans presque tous les cas, si vous voyez nobody Dans les listes d'utilisateurs et de groupes des clients, le problème est la traduction de l'ID de domaine de nom d'utilisateur ou de groupe entre Cloud Volumes Service et le client NFS. Pour éviter ce scénario, utilisez LDAP pour résoudre les informations d'utilisateur et de groupe entre les clients et Cloud Volumes Service.

Si vous utilisez NFSv4.1, un mappage de chaîne de nom a lieu lors des opérations NFS, comme décrit précédemment.

En plus de l'utilisation /var/log/messages Pour trouver un problème avec les ID NFSv4, vous pouvez utiliser le "nfsidmap -l" Commande sur le client NFS pour afficher les noms d'utilisateur qui sont correctement mappés au domaine NFSv4.

Par exemple, ceci est la sortie de la commande après un utilisateur qui peut être trouvé par le client et que Cloud Volumes Service accède à un montage NFSv4.x :

Lorsqu'un utilisateur qui ne se mappe pas correctement dans le domaine ID NFSv4.1 (dans ce cas, netapp-user) essaie d'accéder au même montage et touche un fichier, ils sont affectés nobody:nobody, comme prévu.

Le nfsidmap -l la sortie affiche l'utilisateur pcuser à l'écran, mais pas netapp-user; il s'agit de l'utilisateur anonyme dans notre règle d'export-policy (65534).