Cette section aborde les sujets suivants :
Pour plus d'informations sur le protocole NFS, consultez les rubriques suivantes :
NFSv2 and NFSv3 Security (RFC 2623) (http://www.ietf.org/rfc/rfc2623.txt)
NFSv4 Protocol (RFC 3530) (http://www.ietf.org/rfc/rfc3530.txt)
Pour plus d'informations sur les autres protocoles pris en charge, reportez-vous aux sections suivantes :
Chaque partage possède des propriétés de protocole spécifiques qui définissent le comportement de différents protocoles pour ce partage. Ces propriétés peuvent être définies pour chaque partage ou héritées d'un partage contenu dans un projet. Le tableau suivant présente les propriétés de protocole NFS et leurs valeurs possibles.
|
Des exceptions au mode de partage global peuvent être définies pour les clients ou les collections de clients en définissant des modes de partage spécifiques au client ou des exceptions. Il est recommandé de définir le mode de partage global sur none afin de limiter l'accès pour certains clients, puis d'octroyer progressivement un accès de plus en plus large à des groupes de plus en plus restreints. Par exemple, vous pouvez créer un partage avec le mode de partage global none (qui refuse l'accès à tous les clients), puis accorder un accès en lecture seule à un sous-ensemble de clients. Ensuite, vous pouvez accorder l'accès en lecture et écriture à un sous-ensemble encore plus réduit de clients, et finalement l'accès en lecture-écriture et root aux seuls hôtes sécurisés.
Les modes de partage spécifiques au client priment sur le mode de partage global. L'accès est accordé à un client en fonction du mode de partage spécifique au client spécifié dans une exception. En l'absence d'exceptions, l'accès est accordé au client sur la base du mode de partage global.
|
Pour chaque client ou collection de clients, spécifiez si le client dispose d'un accès en lecture seule ou en lecture/écriture au partage. Si vous définissez une exception NFS, spécifiez également si le client dispose des privilèges d'un utilisateur root ou s'il doit être traité comme un utilisateur sans accès root.
Il est possible d'utiliser des groupes réseau pour le contrôle d'accès lors des exportations NFS. La gestion de groupes réseau peut toutefois s'avérer complexe. A la place, vous pouvez envisager d'utiliser des règles de sous-réseau IP ou des règles de domaine DNS.
Si des groupes réseau sont utilisés, ils seront résolus à partir de NIS ou LDAP, selon le service activé. Si LDAP est utilisé, chaque groupe réseau doit se trouver à l'emplacement par défaut, ou=Netgroup,(Base DN) et doit utiliser le schéma standard.
En général, le composant nom d'utilisateur d'une entrée de groupe réseau n'a aucune conséquence sur NFS, contrairement au composant nom d'hôte. Les noms d'hôte contenus dans les groupes réseau doivent être canoniques et, s'ils ont été choisis à l'aide de DNS, ils doivent être complets. Concrètement, le sous-système NFS tente de vérifier que l'adresse IP du client qui a fait la demande soit résolue en nom d'hôte canonique qui correspond soit au nom de domaine complet (FQDN) indiqué, soit à un membre d'un des groupes réseau spécifiés. Cette correspondance doit être exacte, y compris concernant les composants de domaine. Dans le cas contraire, l'exception n'est pas valide et on passe à l'exception suivante. Pour plus d'informations sur la résolution du nom d'hôte, consultez la section DNS.
Depuis la version logicielle 2013.1.0, les utilisateurs de clients UNIX peuvent appartenir à un maximum de 1 024 groupes sans aucune perte de performance. Les versions précédentes prenaient en charge jusqu'à 16 groupes par utilisateur de client UNIX.
Dans la CLI, tous les modes de partage NFS et les exceptions sont spécifiés à l'aide d'une chaîne d'options unique pour la propriété sharenfs. Cette chaîne est une liste de valeurs séparées par des virgules. Elle doit commencer par ro, rw, on ou off, de la même manière que pour les modes de partage globaux décrits dans la BUI.
|
L'exemple suivant définit le mode de partage en lecture seule pour tous les clients. Les utilisateurs root sur tous les clients accèdent aux fichiers du partage comme s'ils étaient l'utilisateur générique "nobody".
set sharenfs=ro
L'une ou les deux options nosuid et anon peuvent également être ajoutées. Par conséquent, pour définir le mappage de tous les utilisateurs inconnus sur l'UID 153762, vous devez spécifier ceci :
set sharenfs="ro,anon=153762"
Il est possible de spécifier des exceptions NFS supplémentaires en ajoutant du texte sous la forme ro, rw ou root, qui définit le type d'accès à octroyer à la collection de clients. La collection est spécifiée par le caractère de préfixe provenant du tableau Types de client et par un nom de domaine/d'hôte DNS ou un numéro de réseau CIDR. Par exemple, pour octroyer l'accès en lecture-écriture à tous les hôtes du domaine sf.example.com et l'accès root aux hôtes du réseau 192.168.44.0/24, vous devez utiliser :
set sharenfs="ro,anon=153762,rw=.sf.example.com,root=@192.168.44.0/24"
Les noms de groupe réseau peuvent être utilisés partout où un nom d'hôte complet peut être utilisé. Par exemple, vous pouvez autoriser l'accès en lecture-écriture au groupe réseau "engineering" comme suit :
set sharenfs="ro,rw=engineering"
Normalement, le codage de jeu de caractères utilisé pour le nom de fichier n'est pas spécifié. Les protocoles NFSv3 et NFSv2 ne spécifient pas le jeu de caractères. NFSv4 est censé utiliser UTF-8 mais ce n'est pas le cas de tous les clients et cette restriction n'est pas appliquée par le serveur. Si l'option UTF-8 uniquement est désactivée pour un partage, ces noms de fichiers sont écrits in extenso dans les systèmes de fichiers sans aucune connaissance de leurs codages. Cela signifie qu'ils peuvent être interprétés uniquement par les clients qui utilisent le même codage. En revanche, SMB nécessite que les noms de fichiers soient stockés en UTF-8 afin qu'ils puissent être interprétés côté serveur. Il est donc impossible de prendre en charge des codages client arbitraires tout en autorisant l'accès sur SMB.
Pour prendre en charge des configurations de ce type, le codage de jeu de caractère peut être défini au niveau de tout le partage ou par client. Les codages de jeu de caractères suivants sont pris en charge :
|
Le comportement par défaut est de ne pas spécifier le codage de jeu de caractères (intercommunication). La BUI permet de choisir le jeu de caractères via le mécanisme de liste d'exception standard. Dans la CLI, chaque jeu de caractère devient une option ayant ou plusieurs hôtes et où le symbole étoile "*" indique le paramétrage du partage. Par exemple :
hostname:shares default> set sharenfs="rw,euc-kr=*"
partage le système de fichiers avec le codage par défaut "euc-kr". Par exemple,
hostname:shares default> set sharenfs="rw,euc-kr=host1.domain.com,euc-jp=host2.domain.com"
utilise le codage par défaut pour tous les clients sauf "host1" et "host2" qui utilisent respectivement "euc-kr" et "euc-jp". Le format des listes hôtes est similaire à celui des autres options NFS de la CLI.
Notez que les clients NFS ne prennent pas correctement en charge les autres paramètres locaux. Consultez la documentation client NFS pour obtenir de plus amples détails.
Les modes de sécurité sont définis par partage. La liste suivante décrit les paramètres de sécurité Kerberos.
krb - Authentification d'utilisateur final via Kerberos V5
krb5i - krb5 plus préservation de l'intégrité (les paquets de données résistent aux dégradations)
krb5p - krb5i plus préservation de la confidentialité (les paquets de données résistent aux dégradations et sont chiffrés)
Les modes de sécurité sont spécifiés en ajoutant du texte sous la forme "option=mode", où option correspond à sec et mode est le paramètre de sécurité. Par exemple :
hostname: shares default> set sharenfs="sec=krb5"
Les combinaisons de types de Kerberos peuvent être spécifiées dans le paramètre du mode de sécurité. La combinaison de modes de sécurité permet aux clients de monter n'importe quel type de Kerberos répertorié, comme indiqué dans le tableau suivant.
|
Ports réservés
Pour définir des ports réservés pour l'authentification système, utilisez resvport comme indiqué dans cet exemple :
set sharenfs="sec=sys,rw,resvport"
Notez que resvport ne peut être utilisé qu'avec le mode de sécurité d'authentification système sec=sys.