Ignorer les liens de navigation | |
Quitter l'aperu | |
Gestion de systèmes de fichiers réseau dans Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français) |
1. Gestion des systèmes de fichiers NFS (présentation)
2. Administration de système de fichiers réseau (tâches)
3. Accès aux systèmes de fichiers réseau (référence)
Fichiers de configuration et nfsmapid
nfsmapid et enregistrements DNS TXT
Vérification du domaine de la version 4 de NFS
Configuration du domaine par défaut de la version 4 de NFS
Configuration d'un domaine par défaut de la version 4 de NFS dans la version Solaris 11
Configuration d'un domaine par défaut de la version 4 de NFS dans la version Solaris 10
Informations complémentaires sur nfsmapid
Options mount pour les systèmes de fichiers NFS
Utilisation de la commande mount
Options share non spécifiques aux systèmes de fichiers
Options share spécifiques à NFS
Définition des listes d'accès avec la commande share
Commandes pour le dépannage des problèmes liés à NFS
Négociation de version dans NFS
Fonctionnalités de la version 4 de NFS
Annulation et rétablissement du partage d'un système de fichiers dans la version 4 de NFS
Espace de noms du système de fichiers dans la version 4 de NFS
Identificateurs de fichiers volatile de la version 4 de NFS
Récupération d'un client dans la version 4 de NFS
Prise en charge du partage OPEN dans la version 4 de NFS
Délégation dans la version 4 de NFS
Listes de contrôle d'accès (ACL) et nfsmapid dans la version 4 de NFS
Motifs d'échecs de mappages d'ID
Prévention des problèmes de mappage d'ID avec les ACL
Vérification d'ID d'utilisateur ou de groupe non mappé
Informations supplémentaires sur les ACL ou nfsmapid
Négociation de la taille de transfert de fichiers
Montage des systèmes de fichiers
Effets de l'option -public et des URL NFS lors du montage
Qu'est-ce qu'un système de fichiers répliqué ?
Basculement et verrouillage NFS
Basculement côté client dans la version 4 de NFS
Fonctionnement de la journalisation du serveur NFS
Fonctionnement du service WebNFS
Fonctionnement de la négociation de sécurité WebNFS
Fonctionnement des montages miroir
Cas d'utilisation des montages miroir
Montage d'un système de fichiers à l'aide de montages miroir
Démontage d'un système de fichiers recourant à des montages miroir
Fonctionnement des références NFS
Cas d'utilisation des références NFS
Suppression d'une référence NFS
Fonctionnement de la navigation par Autofs dans le réseau (mappes)
Démarrage du processus de navigation par autofs (mappe principale)
Variables d'une entrée de mappe Autofs
Mappes faisant référence à d'autres mappes
Modification de la navigation du réseau par Autofs (modification des mappes)
Les sections suivantes décrivent certaines des fonctions complexes du logiciel NFS. Notez qu'une partie de la description des fonctions de cette section s'applique exclusivement à la version 4 de NFS.
Remarque - Si votre système comporte des zones activées et que vous souhaitez utiliser cette fonction dans une zone non globale, reportez-vous au manuel Administration d’Oracle Solaris 11.1 : Oracle Solaris Zones, Oracle Solaris 10 Zones et gestion des ressources pour plus d'informations.
Le processus de lancement de NFS inclut la négociation des niveaux de protocole pour les serveurs et les clients. Si vous ne spécifiez pas le niveau de version, le meilleur niveau est sélectionné par défaut. Par exemple, si le client et le serveur prennent en charge la version 3, cette version est utilisée. Si le client ou le serveur ne peut prendre en charge que la version 2, cette version est utilisée.
Vous pouvez définir les paramètres client_versmin, client_versmax, server_versmin et server_versmax à l'aide de la commande sharectl. Les valeurs minimum et maximum spécifiées pour le serveur et le client remplacent les valeurs par défaut de ces mots-clés. Pour le client et le serveur, la valeur minimum par défaut est 2 et la valeur maximale par défaut est 4. Pour trouver la version prise en charge par le serveur, le client NFS commence avec le paramètre de client_versmax et essaie ensuite chaque version jusqu'à atteindre le paramètre de version de client_versmin. Dès que la version prise en charge est trouvée, le processus se termine. Par exemple, si client_versmax=4 et que client_versmin=2, le client essaie d'abord la version 4, puis la version 3 et enfin la version 2. Si client_versmax et client_versmin sont définis sur la même valeur, le client utilise toujours cette version et n'essaie pas d'autre version. Si le serveur n'offre pas cette version, le montage échoue.
Remarque - Vous pouvez remplacer les valeurs qui sont déterminées par la négociation en utilisant l'option vers avec la commande mount. Reportez-vous à la page de manuel mount_nfs(1M).
Pour des informations sur les procédures à suivre, reportez-vous à la rubrique Configuration des services NFS.
De nombreuses modifications ont été apportées à NFS dans la version 4. Cette section fournit les descriptions de ces nouvelles fonctionnalités.
Annulation et rétablissement du partage d'un système de fichiers dans la version 4 de NFS
Espace de noms du système de fichiers dans la version 4 de NFS
Listes de contrôle d'accès (ACL) et nfsmapid dans la version 4 de NFS
Remarque - A partir de la version Solaris 10, la version 4 de NFS ne prend pas en charge la variante de sécurité LIPKEY/SPKM. De plus, la version 4 de NFS n'utilise pas les démons mountd , nfslogd et statd.
Pour des informations sur l'utilisation de la version 4 de NFS, reportez-vous à Configuration des services NFS.
Dans les versions 3 et 4 de NFS, si un client tente d'accéder à un système de fichiers dont le partage a été annulé, le serveur renvoie un code d'erreur. Cependant, avec la version 3 de NFS, le serveur conserve tous les verrous que les clients avaient obtenu avant que l'annulation du partage du système de fichiers. Par conséquent, lorsque le partage du système de fichiers est rétabli, les clients de la version 3 de NFS peuvent accéder au système de fichiers comme si son partage n'avait jamais été annulé.
Avec la version 4 de NFS, lorsqu'un système de fichiers n'est pas partagé, tous les états de tout fichier ouvert ou de tout verrou de fichier dans ce système de fichiers sont détruits. Si le client tente d'accéder à ces fichiers ou à ces verrous; il reçoit un message d'erreur. Généralement, cette erreur est signalée comme étant une erreur I/O à l'application. Notez, cependant, que le rétablissement du partage d'un système de fichiers partagé pour modifier les options ne détruit aucun état sur le serveur.
Pour obtenir des informations connexes, reportez-vous à la rubrique Récupération d'un client dans la version 4 de NFS ou à la page de manuel unshare_nfs(1M).
Les serveurs de la version 4 de NFS créent et mettent à jour un pseudo-système de fichiers qui donne aux clients un accès transparent à tous les objets exportés sur le serveur. Dans les versions antérieures à la version 4 de NFS, le pseudo-système de fichiers n'existait pas. Les clients devaient monter chaque système de fichiers de serveur partagé pour l'accès. Voyez l'exemple suivant :
Figure 3-2 Vues du système de fichiers du serveur et du système de fichiers client
Notez que le client ne peut pas voir les répertoires payroll et nfs4x, car ces répertoires ne sont pas exportés et ne mènent pas à des répertoires exportés. Toutefois, le répertoire local est visible pour le client, car local est un répertoire exporté. Le répertoire projects est visible pour le client, car projects mène vers le répertoire exporté, nfs4. Par conséquent, certaines parties de l'espace de noms du serveur qui ne sont pas explicitement exportées sont reliées par un pont avec un pseudo-système de fichiers qui affiche uniquement les répertoires exportés et ceux qui mènent à des exports de serveur.
Un pseudo-système de fichiers est une structure qui contient uniquement des répertoires et est créée par le serveur. Le pseudo-système de fichiers permet à un client de parcourir la hiérarchie des systèmes de fichiers exportés. Par conséquent, la vue du client du pseudo-système de fichiers est limitée aux chemins qui conduisent à systèmes de fichiers exportés.
Les versions précédentes de NFS n'autorisaient pas un client de parcourir les systèmes de fichiers serveur sans monter chaque système de fichiers. Cependant, dans la version 4 de NFS, l'espace de noms de serveur se comporte comme suit :
Restreint la vue du système de fichiers du client vers des répertoires qui conduisent à des exports de serveur.
Fournit aux clients un accès continu aux exports de serveur sans nécessiter que le client monte chaque système de fichiers sous-jacent. Reportez-vous à l'exemple précédent. Notez, toutefois, que différents systèmes d'exploitation peuvent nécessiter que le client monte chaque système de fichiers du serveur.
Les identificateurs de fichiers sont créés sur le serveur et contiennent des informations qui identifient de manière unique les fichiers et les répertoires. Dans les versions 2 et 3 de NFS le serveur renvoyait des identificateurs de fichier persistants. Par conséquent, le client pouvait garantir que le serveur génèrerait un identificateur de fichier qui désigne toujours le même fichier. Par exemple :
Si un fichier est supprimé et remplacé par un autre fichier du même nom, le serveur peut générer un nouvel identificateur de fichier pour le nouveau fichier. Si le client utilise l'ancien identificateur de fichier, le serveur renvoie une erreur d'identificateur de fichier obsolète.
Si un fichier est renommé, l'identificateur de fichier reste le même.
En cas de réinitialisation du serveur, les identificateurs de fichiers restent les mêmes.
Par conséquent, lorsque le serveur a reçu une demande d'un client qui comporte un identificateur de fichier, la résolution est simple et l'identificateur de fichier désigne toujours le fichier approprié.
Cette méthode d'identification des fichiers et répertoires pour les opérations NFS convient à la plupart des serveurs UNIX. Cependant, elle n'a pas pu être implémentée sur les serveurs s'appuyant sur d'autres méthodes d'identification telles que le chemin d'accès d'un fichier. Pour résoudre ce problème, le protocole de la version 4 de NFS permet à un serveur de déclarer ses identificateurs de fichier comme étant volatiles. Ainsi, un identificateur de fichier peut changer. Si l'identificateur de fichier est modifié, le client doit trouver le nouvel identificateur.
Comme pour les versions 2 et 3 de NFS, le serveur de la version 4 de Oracle Solaris NFS fournit toujours des identificateurs de fichier persistants. Toutefois, les clients de la version 4 de Solaris NFS qui accèdent à des serveurs non équipés de la version 4 de Solaris NFS doivent prendre en charge les identificateurs de fichier volatiles si le serveur les utilise. En particulier, lorsque le serveur indique au client que l'identificateur de fichier est volatile, le client doit mettre en cache le mappage entre le nom du chemin d'accès et l'identificateur de fichier. Le client utilise l'identificateur de fichier volatile jusqu'à ce qu'il expire. Lors de son expiration, le client effectue les opérations suivantes :
efface les informations mises en cache qui se rapportent à cet identificateur de fichier ;
recherche le nouvel identificateur de fichier ;
retente l'opération.
Remarque - Le serveur indique toujours au client quels identificateurs de fichier sont persistants ou volatiles.
Les identificateurs de fichier volatiles peuvent expirer pour l'une des raisons suivantes :
Lorsque vous fermez un fichier.
Lorsque le système de fichiers de l'identificateur de fichier migre.
Lorsqu'un client renomme un fichier.
Lorsque le serveur se réinitialise.
Notez que si le client n'est pas en mesure de trouver le nouvel identificateur de fichier, un message d'erreur est placé dans le fichier syslog. Les autres tentatives d'accès à ce fichier échouent avec une erreur I/O.
Le protocole de la version 4 de NFS est un protocole avec état. Un protocole est avec état lorsque le client et le serveur assurent la maintenance des informations sur les éléments suivants.
Fichiers ouverts
Verrous de fichier
Lorsqu'une panne se produit, comme une panne de serveur, le client et le serveur collaborent pour rétablir les états d'ouverture et de verrouillage qui existaient avant cette panne.
Si un serveur s'arrête brutalement et est réinitialisé, le serveur perd son état. Le client détecte que le serveur s'est réinitialisé et commence le processus pour aider le serveur à reconstruire son état. Ce processus est appelé restauration du client, car le client dirige le processus.
Lorsque le client détecte que le serveur s'est réinitialisé, le client suspend immédiatement son activité actuelle et lance le processus de récupération du client. Lorsque le processus de récupération démarre, un message tel que le suivant s'affiche dans le journal d'erreurs système /var/adm/messages.
NOTICE: Starting recovery server basil.example.company.com
Au cours du processus de récupération, le client envoie les informations du serveur à propos de l'état précédent du client. Notez cependant que, pendant cette période, le client n'envoie pas de nouvelles demandes pour le serveur. Toutes les nouvelles demandes d'ouverture de fichiers ou de définition de verrous de fichiers doit attendre que le serveur termine le processus de récupération avant de poursuivre.
Lorsque la récupération du client est terminée, le message suivant s'affiche dans le journal d'erreurs système /var/adm/messages.
NOTICE: Recovery done for server basil.example.company.com
Maintenant, le client a terminé l'envoi des informations d'état pour au serveur. Toutefois, même si le client a terminé ce processus, d'autres clients n'ont peut-être pas été terminé leur processus d'envoi informations d'état au serveur. Par conséquent, le serveur n'accepte pas les demandes d'ouverture ou de verrouillage pendant un certain temps. Cette période appelée délai de grâce, permet à tous les clients de terminer leur processus de récupération.
Au cours de la période de grâce, si le client tente d'ouvrir de nouveaux fichiers ou d'établir de nouveaux verrous, le serveur refuse la demande avec le code d'erreur GRACE. A la réception de l'erreur, le client doit attendre la fin de la période de grâce, puis renvoyer la demande au serveur. Pendant la période de grâce, le message suivant s'affiche.
NFS server recovering
Notez que pendant la période de grâce, les commandes qui n'ouvrent pas les fichiers ou ne définissent pas de verrouillages peuvent s'effectuer. Par exemple, les commandes ls et cd n'ouvrent par de fichiers ni ne définissent un verrouillage de fichier. Par conséquent, ces commandes ne sont pas suspendues. Toutefois, une commande telle que cat, qui ouvre un fichier, serait suspendue jusqu'à ce que la période de grâce se termine.
Lorsque la période de grâce est terminée, le message suivant s'affiche.
NFS server recovery ok.
Le client peut maintenant envoyer de nouvelles demandes d'ouverture et de verrouillage au serveur.
La récupération du client peut échouer pour diverses raisons. Par exemple, si une partition réseau existe après la réinitialisation du serveur, le client peut ne pas être en mesure de rétablir son état avec le serveur avant la fin de la période de grâce. Lorsque la période de grâce est terminée, le serveur n'autorise pas le client afin de rétablir son état parce que de nouvelles opérations d'état pourraient créer des conflits. Par exemple, un nouveau verrou de fichier peut entrer en conflit avec un ancien verrou de fichier que le client tente de récupérer. Lorsque de telles situations se produisent, le serveur renvoie le code d'erreur NO_GRACE au client.
Si la récupération d'une opération d'ouverture pour un fichier en particulier échoue, le client identifie le fichier comme inutilisable et le message suivant s'affiche.
WARNING: The following NFS file could not be recovered and was marked dead (can't reopen: NFS status 70): file : filename
Notez que le nombre 70 n'est qu'un exemple.
Si le rétablissement d'un verrou de fichier échoue pendant la restauration, le message d'erreur suivant est publié.
NOTICE: nfs4_send_siglost: pid PROCESS-ID lost lock on server SERVER-NAME
Dans cette situation, le signal SIGLOST est publié dans le processus. L'action par défaut pour le signal SIGLOST est de mettre fin au processus.
Pour vous permettre de restaurer à partir de cet état, vous devez redémarrer toutes les applications qui avaient des fichiers ouverts au moment de la panne. Notez que les événements suivants peuvent se produire.
Certains processus qui n'ont pas rouvert le fichier peut recevoir des erreurs d'E/S.
D'autres processus ont rouvert le fichier, ou ont exécuté l'opération d'ouverture après la restauration après panne, sont en mesure d'accéder au fichier sans aucun problème.
Par conséquent, certains processus peuvent accéder à un fichier en particulier tandis que d'autres processus ne le peuvent pas.
Le protocole de la version 4 de NFS offre plusieurs modes partage de fichiers que le client peut utiliser pour contrôler l'accès aux fichiers par d'autres clients. Un client peut spécifier les éléments suivants :
Le mode DENY_NONE donne aux autres clients l'accès en lecture et en écriture à un fichier.
Le mode DENY_READ refuse aux autres clients l'accès en lecture à un fichier.
Le mode DENY_WRITE refuse aux autres clients l'accès en écriture à un fichier.
Le mode DENY_BOTH mode refuse aux autres clients l'accès en lecture et en écriture à un fichier.
Le serveur de la version 4 de Oracle Solaris NFS effectue une implémentation complète de ces modes de partage de fichier. Par conséquent, si un client tente d'ouvrir un fichier d'une manière qui entre en conflit avec le mode de partage, le serveur refuse la tentative en faisant échouer l'opération. Lorsque de telles tentatives échouent avec le lancement des opérations de création ou d'ouverture, le client de la version 4 de NFS reçoit une erreur de protocole. Cette erreur est mise en correspondance avec l'erreur d'application EACCES.
Même si le protocole offre plusieurs modes de partage, actuellement, l'opération d'ouverture dans Oracle Solaris n'offre pas plusieurs modes de partage. Lors de l'ouverture d'un fichier, un client de la version 4 de Oracle Solaris NFS peut uniquement utiliser le mode DENY_NONE.
Bien que l'appel de système fcntl dispose d'une commande F_SHARE pour contrôler le partage de fichiers, les commandes fcntl ne peuvent pas être implémentées correctement avec la version 4 de NFS. Si vous utilisez ces commandes fcntl sur un client de la version 4 de NFS, le client renvoie l'erreur EAGAIN à l'application.
La version 4 de NFS fournit à la fois la prise en charge du client et la prise en charge du serveur pour la délégation. La délégation est une technique par laquelle le serveur délègue la gestion d'un fichier à un client. Par exemple, le serveur peut attribuer une délégation de lecture ou d'écriture à un client. Les délégations de lecture peuvent être accordées à plusieurs clients en même temps, car ces délégations de lecture n'entrent pas en conflit les unes avec les autres. Une délégation d'écriture peut être accordée à un seul client, car une telle délégation peut entrer en conflit avec tout autre accès de fichier par tout autre client. Lorsqu'il détient une délégation d'écriture, le client n'enverrait pas diverses opérations sur le serveur car le client est se voit accorder un accès exclusif à un fichier. De même, le client n'envoie pas diverses opérations au serveur tout en détenant une délégation de lecture. La raison est que le serveur garantit qu'aucun client ne peut ouvrir un fichier en mode écriture. L'effet de la délégation est de réduire considérablement les interactions entre le serveur et le client pour les fichiers délégués. Par conséquent, le trafic réseau est réduit et les performances sur le client et le serveur sont améliorées. Notez, cependant, que le degré d'amélioration des performances dépend du type d'interaction de fichier utilisé par une application et la quantité de surcharge sur le réseau ou le serveur.
La décision d'accorder ou non une délégation revient exclusivement au serveur. Un client ne demande pas de délégation. Le serveur prend des décisions concernant la cession d'une délégation, basée sur les modèles d'accès du fichier. Si différents clients ont récemment accédé à un fichier en mode écriture, le serveur peut ne pas accorder de délégation. La raison est que ce modèle d'accès indique le potentiel de conflits futurs.
Un conflit survient lorsqu'un client accède à un fichier d'une manière qui n'est pas cohérente avec les délégations actuellement accordées à ce fichier. Par exemple, si un client détient une délégation d'écriture sur un fichier et qu'un deuxième client ouvre ce fichier pour lire ou écrire l'accès, le serveur rappelle la délégation d'écriture du premier client. De même, si un client détient une délégation de lecture et qu'un autre client ouvre le même fichier pour l'écriture, le serveur rappelle la délégation de lecture. Notez que dans les deux cas, le second client ne se voit pas accorder de délégation parce qu'un conflit existe maintenant. Lorsqu'un conflit survient, le serveur utilise un mécanisme de rappel pour contacter le client qui détient actuellement la délégation. Lors de la réception de ce rappel, le client envoie l'état mis à jour du fichier au serveur et renvoie la délégation. Si le client ne répond pas au rappel, le serveur révoque la délégation. Dans de tels cas, le serveur rejette toutes les opérations provenant du client pour ce fichier, et le client rapporte les opérations demandées comme ayant échoué. En règle générale, ces défaillances sont signalées à l'application comme des erreurs d'E/S. Pour restaurer à partir de ces erreurs, le fichier doit être fermé, puis rouvert. Les échecs de délégations révoquées peuvent se produire lorsqu'une partition de réseau existe entre le client et le serveur, lorsque le client détient une délégation.
Notez qu'un serveur n'est pas en mesure de résoudre les conflits d'accès à un fichier qui est stocké sur un autre serveur. Par conséquent, un serveur NFS résout uniquement les conflits pour les fichiers qu'il stocke. En outre, en réponse aux conflits causés par des clients qui exécutent différentes versions de NFS, un serveur NFS peut uniquement lancer des rappels pour le client qui exécute la version 4 de NFS. Un serveur NFS ne peut pas initier de rappels pour les clients qui exécutent des versions antérieures de NFS.
Le processus de détection des conflits varie. Par exemple, contrairement à la version 4 de NFS, dans la mesure où les versions 2 et 3 n'ont pas de procédure d'ouverture, le conflit n'est détecté qu'après une tentative de lecture, d'écriture ou de verrouillage d'un fichier par un client. La réponse du serveur à ces conflits varie également. Par exemple :
Pour la version 3 de NFS, le serveur renvoie l'erreur juke-box, ce qui fait que le client interrompt la demande d'accès et réessaie plus tard. Le client imprime le message File unavailable.
Pour la version 2 de NFS, l'équivalent de l'erreur JUKEBOX n'existant pas, le serveur n'envoie aucune réponse, ce qui fait que le client va attendre, puis réessayer. Le client imprime le message NFS server not responding.
Ces conditions sont supprimées une fois le conflit de délégation résolu.
Par défaut, la délégation de serveur est activée. Vous pouvez désactiver la délégation en définissant le paramètre server_delegation sur aucun. Pour des informations sur les procédures à suivre, reportez-vous à la rubrique Sélection de versions différentes de NFS sur un serveur.
Aucun mot de passe n'est requis pour la délégation de client. Le démon de rappel de la version 4 de NFS, nfs4cbd, fournit le service de rappel sur le client. Ce démon démarre automatiquement dès qu'un montage pour la version 4 de NFS est activé. Par défaut, le client fournit les informations de rappel pour le serveur pour tous les transports Internet répertoriés dans le fichier système /etc/netconfig. Notez que si le client est compatible avec IPv6 et que l'adresse IPv6 pour le nom du client peut être déterminée, le démon de rappel accepte les connexions IPv6.
Le démon de rappel utilise un numéro de programme transitoire et un numéro de port attribué de façon dynamique. Ces informations sont fournies au serveur et ce dernier vérifie le chemin de rappel avant d'accorder les délégations. Si la vérification du chemin de rappel échoue, le serveur n'accorde pas de délégations (il s'agit du seul comportement visible de l'extérieur).
Notez que dans la mesure où les informations de rappel sont intégrées à une demande de la version 4 de NFS, le serveur n'est pas en mesure de contacter le client par le biais d'un périphérique qui utilise la méthode NAT (Network Address Translation). En outre, le démon de rappel utilise un numéro de port dynamique. Par conséquent, le serveur peut ne pas être en mesure de traverser un pare-feu, même si ce pare-feu autorise normalement le trafic NFS sur le port 2049. Dans de telles situations, le serveur n'accorde pas de délégations.
Une liste de contrôle d'accès (ACL) offre une meilleure sécurité pour les fichiers en permettant au propriétaire d'un fichier de définir les autorisations de fichier pour un propriétaire du fichier, un groupe et autres utilisateurs et groupes spécifiques. Sur les systèmes de fichiers ZFS, les ACL sont définies sur le serveur et le client à l'aide de la commande chmod. Pour les systèmes de fichiers UFS, utilisez la commande setfacl. Reportez-vous aux pages de manuel chmod(1) et setfacl(1) pour plus d'informations. Dans la version 4 de NFS, le mappeur d'ID, nfsmapid, est utilisé pour mettre en correspondance un ID d'utilisateur ou de groupe dans les entrées d'ACL sur un serveur et l'ID d'utilisateur ou de groupe dans entrées d'ACL sur un client. L'inverse est également vrai. Les ID d'utilisateur et de groupe dans les entrées d'ACL doivent exister à la fois sur le client et le serveur.
Les situations suivantes peuvent provoquer un échec de mappage d'ID :
Si l'utilisateur ou le groupe existant dans une entrée d'ACL sur le serveur ne peut pas être mis en correspondance avec un utilisateur ou un groupe valide sur le client, l'utilisateur peut consulter l'ACL, mais certains des utilisateurs ou des groupes seront affichés comme “inconnu”.
Par exemple, lorsque vous entrez la commande ls -lv ou ls -lV, le groupe ou l'utilisateur de certaines entrées d'ACL s'affichera comme “inconnu”. Pour plus d'informations sur cette commande, reportez-vous à la page de manuel ls(1).
Si l'ID d'utilisateur ou de groupe dans n'importe quelle entrée d'ACL qui est définie sur le client ne peut pas être mappé vers un ID d'utilisateur ou de groupe valide sur le serveur, les commandes setfacl ou chmod peuvent échouer et renvoyer le message d'erreur Permission denied.
Si le client et le serveur possèdent des valeurs nfsmapid_domain incompatibles, le mappage d'ID échoue. Pour plus d'informations, reportez-vous à la section Démon nfsmapid.
Afin d'éviter les problèmes de mappage d'ID, procédez comme suit :
Assurez-vous que la valeur de nfsmapid_domain est correctement définie.
Assurez-vous que tous les ID d'utilisateur et de groupe dans les entrées d'ACL existent à la fois sur le client et le serveur de la version 4 de NFS.
Pour déterminer si un utilisateur ou un groupe ne peut pas être mappé sur le serveur ou le client, utilisez le script suivant :
#! /usr/sbin/dtrace -Fs sdt:::nfs4-acl-nobody { printf("validate_idmapping: (%s) in the ACL could not be mapped!", stringof(arg0)); }
Remarque - Le nom de la sonde utilisée dans ce script est une interface qui est susceptible de changer à l'avenir. Pour plus d'informations, reportez-vous à la rubrique Stability Levels du manuel Solaris Dynamic Tracing Guide.
Reportez-vous aux rubriques suivantes :
Pendant l'initialisation, le protocole de transport est également négocié. Par défaut, le premier transport orienté connexion pris en charge à la fois sur le client et le serveur est sélectionné. Si la sélection de cette valeur entraine un échec, le premier protocole de transport sans connexion disponible est utilisé. Les protocoles de transport qui sont pris en charge sur un système sont répertoriés dans /etc/netconfig. TCP est le protocole de transport orienté connexion pris en charge par la version. UDP est le protocole de transport sans connexion.
Lorsque les versions du protocole NFS et du protocole de transport sont déterminées par la négociation, la version du protocole NFS est prioritaire sur le protocole de transport. Le protocole de la version 3 de NFS qui utilise UDP a une priorité plus élevée que le protocole de la version 2 de NFS qui utilise TCP. Vous pouvez sélectionner manuellement la version du protocole NFS et le protocole de transport avec la commande mount. Reportez-vous à la page de manuel mount_nfs(1M). Dans la plupart des cas, laissez la négociation sélectionner les meilleures options.
La taille de transfert de fichier établit la taille des tampons utilisés lors du transfert des données entre le client et le serveur. En général, les tailles de transfert importantes sont préférables. Le protocole de la version 3 de NFS a une taille de transfert illimitée. Le client peut offrir une plus petite taille de transfert au moment du montage si nécessaire, mais dans la plupart des cas, ce n'est pas nécessaire.
La taille de transfert n'est pas négociée avec des systèmes qui utilisent le protocole de la version 2 de NFS. Dans ces conditions, la taille maximale de transfert est définie sur 8 Ko.
Vous pouvez utiliser les options -rsize et -wsize pour définir la taille du transfert manuellement avec la commande mount. Vous pouvez être amené à réduire la taille de transfert de certains clients PC. Par ailleurs, vous pouvez augmenter la taille de transfert si le serveur NFS est configuré pour pouvoir utiliser de plus grandes tailles de transfert.
Remarque - A partir de la version Solaris 10, les restrictions concernant les tailles des transferts par câble ont été assouplies. La taille du transfert dépend des possibilités de transport sous-jacent. Par exemple, la limite du transfert NFS pour le protocole UDP est toujours de 32 Ko. Cependant, TCP étant un protocole de transmission ne possédant pas les limites de datagramme UDP, les tailles maximales de transfert via TCP ont été augmentées à 1 Mo.
La description suivante s'applique aux montages de la version 3 de NFS. Le processus de montage de la version 4 de NFS n'inclut ni le service portmap ni le protocole MOUNT.
Lorsqu'un client a besoin de monter un système de fichiers à partir d'un serveur, le client doit obtenir un identificateur de fichier auprès du serveur. L'identificateur de fichier doit correspondre à celui du système de fichiers. Cette procédure nécessite que plusieurs transactions s'effectuent entre le client et le serveur. Dans cet exemple, le client tente de monter /home/terry à partir du serveur. Un suivi snoop pour cette transaction suit.
client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP server -> client PORTMAP R GETPORT port=33492 client -> server MOUNT3 C Null server -> client MOUNT3 R Null client -> server MOUNT3 C Mount /export/home9/terry server -> client MOUNT3 R Mount OK FH=9000 Auth=unix client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP server -> client PORTMAP R GETPORT port=2049 client -> server NFS C NULL3 server -> client NFS R NULL3 client -> server NFS C FSINFO3 FH=9000 server -> client NFS R FSINFO3 OK client -> server NFS C GETATTR3 FH=9000 server -> client NFS R GETATTR3 OK
Dans ce suivi, le client demande d'abord le numéro de port de montage au le service portmap sur le serveur NFS. Une fois que le client reçoit le numéro de port de montage (33492), ce numéro est utilisé pour tester la disponibilité du service sur le serveur. Une fois que le client a déterminé qu'un service est en cours d'exécution sur ce numéro de port, il effectue une demande de montage. Lorsque le serveur répond à cette demande, le serveur inclut l'identificateur de fichier pour le système de fichiers (9000) en cours de montage. Le client envoie ensuite une demande pour le numéro de port NFS. Lorsque le client reçoit le numéro du serveur, il vérifie la disponibilité du service NFS (nfsd). En outre, il demande des informations NFS sur le système de fichiers qui utilise l'identificateur de fichier.
Dans le suivi ci-après, le client monte le système de fichiers avec l'option public.
client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry server -> client NFS R LOOKUP3 OK FH=9000 client -> server NFS C FSINFO3 FH=9000 server -> client NFS R FSINFO3 OK client -> server NFS C GETATTR3 FH=9000 server -> client NFS R GETATTR3 OK
A l'aide de l'identificateur de fichier public par défaut ( 0000), toutes les transactions devant obtenir des informations à partir du service portmap et déterminer le numéro de port NFS sont ignorées.
Remarque - La version 4 de NFS prend en charge les identificateurs de fichiers volatiles. Pour plus d'informations, reportez-vous à la section Identificateurs de fichiers volatile de la version 4 de NFS.
L'option -public peut créer des conditions à l'origine de l'échec d'un montage. L'ajout d'une URL NFS peuvent également causer des problèmes. La liste suivante décrit la façon dont un système de fichiers est monté lorsque vous utilisez ces options.
Option public avec URL NFS : force l'utilisation de l'identificateur de fichier public. Le montage échoue si l'identificateur de fichier public n'est pas pris en charge.
Option public avec chemin d'accès ordinaire : force l'utilisation de l'identificateur de fichier public. Le montage échoue si l'identificateur de fichier public n'est pas pris en charge.
URL NFS uniquement : utilise l'identificateur de fichier public si ce dernier est activé sur le serveur NFS. Si le montage échoue lors de l'utilisation de l'identificateur de fichier public, essayez d'effectuer le montage avec le protocole MOUNT.
Chemin d'accès ordinaire uniquement : n'utilise par l'identificateur de le fichier public. Le protocole MOUNT est utilisé.
En utilisant le basculement côté client, un client NFS peut détecter plusieurs serveurs qui rendent les mêmes données disponibles et peuvent passer à un autre serveur lorsque le serveur actuel n'est pas disponible. Le système de fichiers peut devenir indisponible si l'une des conditions suivantes se produit.
Le système de fichiers est connecté à un serveur qui tombe en panne
Le serveur est en surcharge.
Une panne du réseau se produit.
Le basculement, dans ces conditions, est normalement transparent pour l'utilisateur. Par conséquent, le basculement peut se produire à tout moment et sans perturber les processus qui sont en cours d'exécution sur le client.
Le basculement nécessite que le système de fichiers soit monté en lecture seule. Les systèmes de fichiers doivent être identiques pour que le basculement s'effectue avec succès. Reportez-vous à la section Qu'est-ce qu'un système de fichiers répliqué ? pour obtenir une description de qui fait qu'un système de fichiers est identique. Un système de fichiers statique ou qui n'a pas été modifiée est souvent le meilleur candidat pour un basculement.
Vous ne pouvez pas utiliser CacheFS et le basculement côté client sur un même montage NFS. Des informations supplémentaires sont enregistrées pour chaque système de fichiers CacheFS. Ces informations ne peuvent pas être mises à jour lors du basculement, de sorte que seule l'une de ces fonctions peut être utilisée lors du montage d'un système de fichiers.
Le nombre de répliques devant être établies pour chaque système de fichiers dépend de nombreux facteurs. Dans l'idéal, vous devez disposer d'au moins deux serveurs. Chaque serveur doit prendre en charge plusieurs sous-réseaux. Cette configuration est préférable au fait d'avoir un serveur unique sur chaque sous-réseau. Le processus exige que chaque serveur répertorié soit vérifié. Par conséquent, si plusieurs serveurs sont répertoriés, chaque montage est plus lent.
Pour bien comprendre le processus, vous devez comprendre deux termes.
Basculement : le processus de sélection d'un serveur à partir d'une liste de serveurs qui prennent en charge un système de fichiers répliqué. Normalement, le serveur suivant de la liste triée est utilisé, à moins qu'il ne réponde pas.
Remappage : pour utiliser un nouveau serveur. Grâce à une utilisation normale, les clients stockent le nom du chemin d'accès pour chaque fichier actif sur le système de fichiers distant. Au cours du remappage, ces noms de chemin d'accès sont évalués pour détecter les fichiers sur le nouveau serveur.
Pour les besoins du basculement, un système de fichiers peut être appelé réplique lorsque chaque fichier est de la même taille et a la même taille de fichier ou le même type de fichier que le système de fichiers d'origine. Les autorisations, dates de création et autres attributs de fichier ne sont pas pris en compte. Si la taille du fichier ou les types de fichier sont différents, le remappage échoue et le processus se bloque jusqu'à ce que l'ancien serveur devienne disponible. Dans la version 4 de NFS, le comportement est différent. Reportez-vous à la section Basculement côté client dans la version 4 de NFS.
Vous pouvez gérer un système de fichiers répliqué à l'aide de rsync, cpio ou d'un autre mécanisme de transfert de fichiers. Dans la mesure où la mise à jour des systèmes de fichiers répliqués entraîne des incohérences, prenez les précautions suivantes pour obtenir de meilleurs résultats :
attribution d'un nouveau nom à l'ancienne version du fichier avant d'installer une nouvelle version du fichier ;
exécution des mises à jour pendant la nuit lorsque l'utilisation du client est faible ;
limitation de la taille des mises à jour ;
réduction du nombre de copies.
Certains logiciels requièrent des verrous de lecture sur les fichiers. Pour éviter que ces produits ne dysfonctionnent, les verrous de lecture sur des systèmes de fichiers en lecture seule sont autorisés, mais sont visibles pour le côté client seulement. Les verrous sont conservés par le biais d'un remappage car le serveur n'est pas au courant de l'existence des verrous. Etant donné que les fichiers ne doivent pas changer, vous n'avez pas besoin de verrouiller le fichier sur le côté serveur.
Dans la version 4 de NFS, si une réplique ne peut pas être établie car les tailles ou les types de fichier sont différents, les événements suivants se produisent.
Le fichier est inutilisable.
Un message d'avertissement est imprimé.
L'application reçoit un échec de l'appel système.
Remarque - Si vous redémarrez l'application et essayez à nouveau d'accéder à un fichier, vous devriez y parvenir.
Dans la version 4 de NFS, vous ne recevez plus d'erreurs de réplication pour les répertoires de tailles différentes. Dans les précédentes versions de NFS, cette condition était considérée comme une erreur et entravait le processus de remappage.
En outre, dans la version 4 de NFS, si une opération de répertoire de lecture est infructueuse, l'opération est exécutée par le serveur suivant de la liste. Dans les précédentes versions de NFS, les opérations de lecture ayant échoué risquaient d'entraîner un échec du remappage et un blocage du processus jusqu'à ce que le serveur d'origine soit disponible.
La journalisation du serveur NFS fournit les enregistrements des lectures et écritures NFS, ainsi que des opérations qui modifient le système de fichiers. Ces données peuvent être utilisées pour suivre l'accès aux informations. En outre, ces enregistrements peuvent fournir un moyen quantitatif de mesurer l'intérêt pour l'information.
En cas d'accès à un système de fichiers avec la journalisation activée, le noyau écrit les données brutes dans un fichier tampon. Les données incluent ce qui suit :
un horodatage ;
l'adresse IP du client ;
l'UID du demandeur ;
l'identificateur de fichier de l'objet fichier ou répertoire objet en cours d'accès ;
le type de l'opération qui s'est produite.
Le démon nfslogd convertit ces données brutes en enregistrements au format ASCII qui sont stockés dans des fichiers journaux. Lors de la conversion, les adresses IP sont modifiées en noms d'hôte et les UID sont modifiés en informations de connexion si le service de noms qui est activé peut trouver des correspondances. Les identificateurs de fichiers sont également convertis en noms de chemin d'accès. Pour accomplir la conversion, le démon assure le suivi des identificateurs de fichiers et stocke les informations dans une table identificateur de fichier-chemin d'accès distincte. De cette façon, le chemin d'accès n'a pas à être identifié à nouveau à chaque accession à un identificateur de fichier. Dans la mesure où aucune modification n'est apportée aux mappages dans la table identificateur de fichier-chemin lorsque la commande nfslogd est désactivée, vous devez conserver le démon en cours d'exécution.
Remarque - La journalisation du serveur n'est pas prise en charge dans la version 4 de NFS.
Le service WebNFS rend les fichiers dans un répertoire accessibles par les clients à l'aide d'un identificateur de fichier. Un identificateur de fichier est une adresse qui est générée par le noyau qui identifie un fichier pour les clients NFS. L'identificateur de fichier public a une valeur prédéfinie, de sorte que le serveur n'a pas besoin de générer un identificateur de fichier pour le client. La capacité d'utiliser cet identificateur de fichier prédéfini réduit le trafic réseau en éliminant le protocole MOUNT. Cette capacité devrait également accélérer les processus pour les clients.
Par défaut, l'identificateur de fichier public sur un serveur NFS est établi sur le système de fichiers racine. Cette valeur par défaut fournit l'accès WebNFS à tous les clients disposant déjà de privilèges de montage sur le serveur. Vous pouvez modifier l'identificateur de fichier public pour pointer sur n'importe quel système de fichiers en utilisant la commande share.
Lorsque le client dispose de l'identificateur de fichier pour le système de fichiers, une commande LOOKUP est exécutée pour déterminer l'identificateur du fichier auquel accéder. Le protocole NFS permet l'évaluation d'un seul composant de nom de chemin à la fois. Chaque niveau supplémentaire de hiérarchie de répertoires nécessite une autre opération de LOOKUP. Un serveur WebNFS peut évaluer un nom de chemin d'accès entier à l'aide d'une transaction de recherche de composant multi-transaction lorsque la commande LOOKUP est relative à l'identificateur de fichier public. La recherche de multi-composant permet au serveur WebNFS de fournir l'identificateur de fichier pour le fichier désiré sans échanger d'identificateurs de fichiers pour chaque niveau de répertoire dans le nom du chemin d'accès.
En outre, un client NFS peut lancer des téléchargements simultanés sur une seule connexion TCP. Cette connexion permet d'avoir un accès rapide sans la charge supplémentaire sur le serveur causée par la configuration de plusieurs connexions. Bien que les applications de navigateur Web prennent en charge le téléchargement de plusieurs fichiers, chaque fichier a sa propre connexion. En utilisant une connexion, le logiciel WebNFS réduit le temps système sur le serveur.
Si le composant final dans le nom de chemin est un lien symbolique vers un autre système de fichiers, le client peut accéder au fichier si le client a déjà un accès par l'intermédiaire des activités NFS normale.
En règle générale, l'URL NFS est évaluée par rapport à l'identificateur de fichier public. L'évaluation peut être modifiée de manière à être relative à la racine du serveur du système de fichiers par l'ajout d'une autre barre oblique au début du chemin d'accès. Dans cet exemple, ces deux URL NFS sont équivalentes si l'identificateur de fichier public a été établi sur le système de fichiers /export/ftp.
nfs://server/junk nfs://server//export/ftp/junk
Remarque - Le protocole de la version 4 de NFS est préféré au service WebNFS. La version 4 de NFS intègre pleinement toutes les négociations de sécurité ajoutées au protocole MOUNT et au service WebNFS.
Le service NFS inclut un nouveau protocole qui permet à un client WebNFS de négocier le mécanisme de sécurité sélectionné avec un serveur WebNFS. Le nouveau protocole utilise une recherche de négociation de sécurité multi-composant, qui est une extension de la recherche multi-composant qui a été utilisée dans les versions antérieures du protocole WebNFS.
Le client WebNFS lance le processus en faisant une demande de recherche multi-composant standard en utilisant l'identificateur de fichier public. Puisque le client ne sait pas comment le chemin est protégé par le serveur, le mécanisme de sécurité par défaut est utilisé. Si le mécanisme de sécurité par défaut n'est pas suffisant, la réponse du serveur est une erreur AUTH_TOOWEAK. Cette réponse indique que le mécanisme par défaut n'est pas valide. Le client doit utiliser un mécanisme par défaut plus fort.
Lorsque le client reçoit l'erreur AUTH_TOOWEAK, le client envoie une demande au serveur pour déterminer quels mécanismes de sécurité sont requis. Si la demande réussit, le serveur répond avec un tableau de mécanismes de sécurité requis pour le chemin d'accès spécifié. En fonction de la taille du tableau de mécanismes de sécurité, le client peut être amené à effectuer des demandes supplémentaires pour obtenir le tableau complet. Si le serveur ne prend pas en charge la négociation de sécurité WebNFS, la demande échoue.
Si la demande aboutit, le client WebNFS sélectionne le premier mécanisme de sécurité à partir du tableau que le client prend en charge. Le client émet ensuite une demande de recherche multi-composant standard à l'aide des mécanismes de sécurité pour acquérir l'identificateur de fichier. Toutes les autres demandes NFS sont effectuées à l'aide du mécanisme de sécurité et de l'identificateur de fichier.
Remarque - Le protocole de la version 4 de NFS est préféré au service WebNFS. La version 4 de NFS intègre pleinement toutes les négociations de sécurité ajoutées au protocole MOUNT et au service WebNFS.
Plusieurs fonctions qu'un site Web utilisant HTTP est capable de fournir ne sont pas prises en charge par le logiciel WebNFS. Ces différences proviennent du fait que le serveur NFS n'envoie que le fichier, de sorte que tout traitement spécial doit être effectué par le client. Si vous avez besoin d'un site web configuré pour l'accès WebNFS et HTTP, vous devez tenir compte des points suivants :
La navigation sur NFS n'exécute par les scripts CGI. Par conséquent, un système de fichiers avec un site web actif qui utilise de nombreux scripts CGI pourrait ne pas être approprié pour la navigation NFS.
Le navigateur peut démarrer différents visionneurs pour gérer les identificateurs de fichiers dans différents formats de fichier. L'accès à ces fichiers par le biais d'une URL NFS lance un visionneur externe si le type de fichier peut être déterminé par le nom de fichier. Le navigateur doit reconnaître toute extension de nom de fichier pour un type MIME standard lorsqu'une URL NFS est utilisée. Le logiciel WebNFS n'effectue pas de vérification dans le fichier pour déterminer son type. Par conséquent, le seul moyen de déterminer un type de fichier est son extension de nom.
La navigation NFS ne peut pas utiliser les mappes d'images côté serveur (images cliquables). Cependant, la navigation NFS peut utiliser les mappes d'image côté client (images cliquables) car les URL sont définies avec l'emplacement. Aucune réponse supplémentaire n'est requise pour le serveur de documents.
L'environnement NFS est un moyen efficace et pratique pour partager des systèmes de fichiers sur un réseau doté de diverses architectures et systèmes d'exploitation. Cependant, les mêmes fonctions qui font que le partage des systèmes de fichiers à l'aide des opérations NFS est pratique posent également des problèmes de sécurité. Historiquement, la plupart des implémentations NFS utilisaient l'authentification UNIX (ou AUTH_SYS), mais aussi des méthodes d'authentification plus fortes comme AUTH_DH étaient également disponibles. Lorsque vous utilisez l'authentification UNIX, un serveur NFS authentifie une demande de fichier en authentifiant l'ordinateur qui effectue la demande, mais pas l'utilisateur. Par conséquent, un utilisateur client peut exécuter su et usurper l'identité du propriétaire d'un fichier. Si l'authentification DH est utilisée, le serveur NFS authentifie l'utilisateur, ce qui rend ce type d'usurpation d'identité beaucoup plus difficile.
Avec un accès à la racine et des connaissances en programmation réseau, n'importe qui peut introduire des données arbitraire dans le réseau et extraire des données du réseau. Les attaques les plus dangereuses sont celles qui concernent l'introduction de données. Un exemple est l'usurpation de l'identité d'un utilisateur effectuée en générant les bons paquets ou en enregistrant des conversations et en les rejouant ultérieurement. Ces attaques ont une incidence sur l'intégrité des données. Les attaques qui impliquent l'écoute passive, qui correspond simplement à l'écoute du trafic réseau sans usurpation d'identité, ne sont pas aussi dangereuses, car l'intégrité des données n'est pas compromise. Les utilisateurs peuvent protéger la confidentialité des informations sensibles en chiffrant les données envoyées sur le réseau.
Une approche courante aux problèmes de sécurité réseau consiste à laisser la solution à chaque application. Une meilleure approche consiste à mettre en oeuvre un système d'authentification standard à un niveau qui couvre toutes les applications.
Le système d'exploitation Oracle Solaris inclut un système d'authentification au niveau de l'appel de procédure à distance (RPC), qui est le mécanisme sur lequel les opérations NFS sont construites. Ce système, appelé RPC sécurisé, améliore considérablement la sécurité d'un environnement réseau et fournit une sécurité supplémentaire pour les services tels que le système NFS. Lorsque le système NFS utilise les fonctions qui sont fournies par RPC sécurisé, il est connu comme un système NFS sécurisé.
RPC sécurisé est fondamental pour le système NFS sécurisé. L'objectif de RPC sécurisé est de construire un système qui est au moins aussi sécurisé qu'un système travaillant en temps partagé. Dans un système travaillant en temps partagé, tous les utilisateurs partagent le même ordinateur. Un système travaillant en temps partagé authentifie un utilisateur par le biais d'un mot de passe de connexion. Avec l'authentification DES (Data Encryption Standard), le même processus d'authentification est terminé. Les utilisateurs peuvent se connecter sur n'importe quel ordinateur distant tout comme les utilisateurs peuvent se connecter sur un terminal local. Les mots de passe de connexion sont leur assurance de la sécurité du réseau. Dans un environnement en temps partagé, l'administrateur système a une obligation éthique de ne pas modifier un mot de passe pour usurper l'identité quelqu'un. Dans RPC sécurisé, l'administrateur réseau n'est pas autorisé à modifier les entrées d'une base de données qui stocke les clés publiques.
Vous devez être familier avec deux termes pour comprendre un système d'authentification RPC : informations d'identification et de connexion et vérificateurs. Comme pour les cartes d'identité, les données d'identification sont ce qui identifie une personne : un nom, une adresse et une date de naissance. Le vérificateur est la photo sur la carte. Vous pouvez vérifier que la carte n'a pas été volée en vérifiant la photo sur la carte et en la comparant à la personne qui la détient. Dans RPC, le processus client envoie les informations d'identification et de connexion et un vérificateur au serveur avec chaque demande RPC. Le serveur renvoie uniquement un vérificateur car le client connaît déjà les informations d'identification et de connexion du serveur.
L'authentification RPC est illimitée, ce qui signifie qu'une grande variété de systèmes d'authentification peuvent y être raccordés, comme UNIX, DH et KERB.
Lorsque l'authentification UNIX est utilisée par un service réseau, les informations d'authentification et de connexion contiennent le nom d'hôte du client, l'UID, le GID et la liste d'accès de groupe. Cependant, le vérificateur ne contient rien. Dans la mesure où aucun vérificateur n'existe, un superutilisateur peut falsifier les informations d'identification et de connexion appropriées à l'aide des commandes telles que su. Un autre problème de l'authentification UNIX est qu'elle suppose que tous les ordinateurs d'un réseau sont des ordinateurs UNIX. L'authentification UNIX ne fonctionne pas lorsqu'elle est appliquée à d'autres systèmes d'exploitation dans un réseau hétérogène.
Pour surmonter les problèmes de l'authentification UNIX, le RPC sécurisé utilise l'authentification DH.
L'authentification DH utilise la cryptographie par clé publique DES (Data Encryption Standard) et Diffie-Hellman pour authentifier les utilisateurs et les ordinateurs du réseau. DES est un mécanisme de chiffrement standard. La cryptographie par clé publique Diffie-Hellman est un système de chiffrement qui implique deux clés : une publique et une secrète. Les clés publiques et secrètes sont stockées dans l'espace de noms. NIS stocke les clés dans la mappe de clé publique. Ces mappes contiennent la clé publique et la clé secrète pour tous les utilisateurs potentiels. Reportez-vous au manuel Oracle Solaris Administration: Naming and Directory Services pour plus d'informations sur la configuration des mappes.
La sécurité de l'authentification DH est basée sur la capacité d'un expéditeur à chiffrer l'heure actuelle, que le destinataire peut ensuite déchiffrer et vérifier par rapport à son propre horloge. L'horodatage est chiffré à l'aide de DES. La configuration requise pour que ce plan fonctionne est la suivante :
Les deux agents doivent s'accorder sur l'heure actuelle.
L'expéditeur et le destinataire doivent utiliser la même clé de chiffrement.
Si un réseau exécute un programme de synchronisation d'heure, l'heure sur le client et le serveur est synchronisée automatiquement. Si un programme de synchronisation n'est pas disponible, les horodatages peuvent être calculés à l'aide de l'heure de serveur au lieu de l'heure du réseau. Le client demande l'heure au serveur avant le démarrage de la session RPC, puis calcule la différence de temps entre sa propre horloge et celle du serveur. Cette différence est utilisée pour compenser l'horloge du client lors du calcul des horodatages. Si les horloges du client et du serveur se désynchronisent, le serveur commence à rejeter les demandes du client. Le système d'authentification DH sur le client permet d'effectuer une resynchronisation avec le serveur.
Le client et le serveur arrivent à la même clé de chiffrement en générant une clé de conversation aléatoire également appelée clé de session, et en utilisant la cryptographie par clé publique pour déduire une clé commune. La clé commune est une clé que seuls le client et le serveur sont capables de déduire. La clé de conversation est utilisée pour chiffrer et déchiffrer l'horodatage du client. La clé commune est utilisée pour chiffrer et déchiffrer la clé de conversation.
Kerberos est un système d'authentification qui a été développé au MIT. Kerberos offre une variété de types de chiffrement, y compris DES. La prise en charge de Kerberos n'est plus fournie dans le cadre du RPC sécurisé, mais cette version inclut une implémentation côté serveur et côté client. Reportez-vous au Chapitre 19, Introduction au service Kerberos du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité pour plus d'informations sur l'implémentation de l'authentification Kerberos.
Tenez compte des points suivants si vous avez l'intention d'utiliser le RPC sécurisé :
Si un serveur s'arrête brutalement et que personne n'est à proximité (à la suite d'une panne de courant, par exemple), toutes les clés secrètes qui sont stockées dans le système sont supprimées. Maintenant, aucun processus ne peut accéder aux services réseau sécurisés ou monter un système de fichiers NFS. Les processus importants lors d'une réinitialisation s'exécutent généralement en tant que root. Par conséquent, ces processus fonctionneraient si la clé secrète de la racine était stockée, mais personne n'est disponible pour saisir le mot de passe qui la déchiffre. keylogin -r permet à root de stocker les clé secrètes effacées dans /etc/.rootkey, que keyserv lit.
Certains systèmes s'initialisent en mode monoutilisateur, avec un shell de connexion root sur la console et aucune invite de mot de passe. La sécurité physique est indispensable dans de tels cas.
L'initialisation d'ordinateur sans disque n'est pas totalement sécurisée. Quelqu'un pourrait usurper l'identité du serveur d'amorçage et initialiser un noyau retors qui, par exemple, effectuerait un enregistrement de votre clé secrète sur un ordinateur distant. Le système NFS sécurisé offre une protection uniquement lorsque le noyau et les clés du serveur sont en cours d'exécution. Dans le cas contraire, aucun moyen ne permet d'authentifier les réponses qui sont données par le serveur d'initialisation. Cette limitation pourrait être un problème grave, mais la limitation nécessite une attaque sophistiquées, à l'aide du code source du noyau. En outre, il resterait des preuves du crime. Si vous avez interrogiez le réseau pour les serveurs d'initialisation, vous pourriez détecter l'emplacement du serveur d'initialisation retors.
root est le propriétaire de la plupart des programmes setuid. Si la clé secrète pour root est stockée dans /etc/.rootkey, ces programmes se comportent comme ils ont toujours fait. Si un programme setuid est détenu par un utilisateur, cependant, le programme setuid risque de ne pas toujours fonctionner. Par exemple, supposons qu'un programme setuid est détenu par dave et que dave ne s'est pas connecté à l'ordinateur depuis qu'il a démarré. Le programme ne sera plus capable d'accéder aux services de réseau sécurisé.
Si vous vous connectez à un ordinateur distant (avec login, rlogin ou telnet) et utilisez keylogin pour obtenir un accès, vous donner l'accès à votre compte. La raison est que votre clé secrète est transmise au serveur de clé de l'ordinateur qui stocke ensuite votre clé secrète. Ce processus est un problème uniquement si vous ne faites pas confiance à l'ordinateur distant. Si vous avez des doutes, cependant, ne vous connectez pas à un ordinateur distant si l'ordinateur distant nécessite un mot de passe. Au lieu de cela, utilisez l'environnement NFS pour monter des systèmes de fichiers qui sont partagés par l'ordinateur distant. Vous pouvez également utiliser keylogout pour supprimer la clé secrète du serveur de clés.
Si un répertoire personnel est partagé avec l'option -o sec=dh, établir des connexions distantes peut être un problème. Si les fichiers /etc/hosts.equiv ou ~/.rhosts ne sont pas définis pour demander un mot de passe, la connexion est établie. Toutefois, les utilisateurs ne peuvent pas accéder à leurs répertoires d'accueil car aucune authentification n'a été effectuée localement. Si l'utilisateur est invité à saisir un mot de passe, l'utilisateur a le droit d'accéder à son répertoire personnel si le mot de passe correspond au mot de passe du réseau.