Linux NFS HOWTO <author>Nicolai Langfeldt <tt/jan@math.uio.no/ <date>v0.5, 9 March 1997 <abstract> (Adaptation française par Christophe Deleuze, <tt/deleuze@rp.lip6.fr/, 23 Septembre 1997). HOWTO décrivant l'installation de serveurs et clients NFS. </abstract>  <toc>  <sect>Préambule <sect1>Blabla légal (C)opyright 1997 Nicolai Langfeldt et Alan Cox. Si vous modifiez ce document signalez le dans le copyright, sa distribution est libre à condition de conserver la mention du copyright. (C)opyright 1997 Christophe Deleuze pour la version française. Si vous lisez ce document sous le pont de l'Alma, veillez à respecter les limitations de vitesse. <sect1>Autre blabla Ce document ne sera jamais terminé, merci de m'envoyer par mail vos problèmes et réussites, cela pourra améliorer ce HOWTO. Envoyez argent, commentaires et questions à jan@math.uio.no. Si vous envoyez un mail, <em/vérifiez/ que l'adresse de retour soit correcte et fonctionne, je reçois <em/beaucoup/ de mail et rechercher votre adresse mail peut représenter beaucoup de travail. S'iouplait. Si vous voulez traduire ce HOWTO merci de me le signaler, que je puisse savoir en quels langages j'ai été publié :-). [c'est fait...] Remerciements à Olaf Kirch pour m'avoir convaincu d'écrire ceci, puis fourni de bonnes suggestions. Les commentaires sur la traduction sont à envoyer à Christophe Deleuze, deleuze@rp.lip6.fr. <sect>LISEZMOI.d_abord<label id="intro"> NFS, le système de fichiers par réseau, a deux caractéristiques importantes : <itemize> <item> il permet le partage de fichiers sur un réseau ; <item> il crée tout un tas de problèmes de sécurité bien connus des crackers qui peuvent facilement les exploiter pour obtenir l'accès (lecture, écriture et effacement) à tous vos fichiers. </itemize> Je parlerai de ces deux aspects dans ce HOWTO. Lisez le bien <em/en entier/ et vous supprimerez quelques stupides risques de sécurité. Ne dites pas que je ne vous ai pas prévenus. Les passages sur la sécurité sont parfois assez techniques et demandent quelques connaissances en réseau IP. Si vous ne connaissez pas les termes utilisés vous pouvez soit consulter le HOWTO réseau, improviser ou vous procurer un livre sur l'administration de réseau TCP/IP pour vous familiariser avec TCP/IP. C'est une bonne idée de toutes façons si vous administrez des machines UNIX/Linux. Un très bon livre sur le sujet est TCP/IP Network Administration par Craig Hunt, publié par O'Reilly \& Associates, Inc. Et quand vous l'aurez lu et compris, vous vaudrez plus cher sur le marché du travail, vous ne pouvez qu'y gagner :-) <sect>Installer un serveur NFS<label id="nfs-server"> <sect1>Conditions préalables Avant de continuer à lire ce HOWTO, vous aurez besoin de pouvoir faire des telnet dans les deux sens entre les machines que vous utiliserez comme serveur et client. Si cela ne fonctionne pas, voyez le HOWTO réseau et configurez correctement le réseau. <sect1>Et le premier jour, Dieu dit... Avant de faire quoi que ce soit d'autre, il nous faut un serveur NFS installé. Si vous faites partie d'un département réseau d'une université ou autre, il y a probablement un grand nombre de serveurs NFS qui tournent déjà. Si votre but est d'utiliser un serveur déjà installé alors vous pouvez sauter à la section 4. Si vous devez installer un serveur sur une machine non Linux il vous faudra lire les pages de manuel du système pour trouver comment configurer le serveur NFS et l'exportation des systèmes de fichiers par NFS. Les mot-clés sont : nfsd, outil d'administration système, scripts rc, scripts de démarrage, séquence de démarrage, /etc/exports, exportfs (en anglais system administration tool, rc scripts, boot scripts, boot sequence). Ceci fait, vous pourrez passer à la section suivante de ce HOWTO. Ou continuer à lire cette section vu que certaines des choses que je vais dire sont pertinentes quel que soit le type de machine que vous utilisez comme serveur. Ceux de vous qui continueront la lecture devront configurer un grand nombre de programmes. <sect1>Le portmapper Le portmapper de Linux est appelé soit <tt/portmap/ soit <tt/rpc.portmap/. La page de manuel sur mon système dit que c'est un convertisseur de port DARPA vers numéro de programme RPC. C'est là que se trouve la première faille de sécurité. La gestion de ce problème est décrite à la section 5, que, encore une fois, je vous invite très fortement à lire. Lancez le portmapper. Il devrait être dans le répertoire <tt>/usr/sbin</tt> (sur quelques machines il est appelé rpcbind). Vous pouvez le lancer à la main pour cette fois mais il devra être lancé à chaque démarrage de la machine, il faudra donc créer ou éditer les scripts rc. Les scripts rc sont décrits dans la page de manuel init, ils sont généralement dans <tt>/etc/rc.d</tt>, <tt>/etc/init.d</tt> ou <tt>/etc/rc.d/init.d</tt>. S'il y a un script qui a un nom du genre <tt/inet/, c'est probablement le script à éditer. Mais ce qu'il faut écrire ou faire sort du cadre de ce HOWTO. Lancez portmap, et vérifiez qu'il tourne avec <tt/ps -aux/. Il y est ? Benissimo. <sect1>Mountd et nfsd Les prochains programmes à lancer sont mountd et nfsd. Mais d'abord il faut éditer un autre fichier, <tt>/etc/exports</tt>. Disons que je veux que le système de fichiers <tt>/mn/eris/local</tt> qui est sur la machine <tt/eris/ soit disponible sur la machine <tt/apollon/. Je l'indique dans <tt>/etc/exports</tt> sur eris : <code> /mn/eris/local apollon(rw) </code> La ligne ci-dessus donne à <tt/apollon/ un accès en lecture/écriture sur <tt>/mn/eris/local</tt>. Au lieu de <tt/rw/ on pourrait mettre <tt/ro/ pour <em/read only/ (lecture seule, c'est la valeur par défaut). D'autres options existent, et je parlerai de quelques unes liées à la sécurité plus loin. Elles sont toutes décrites dans la page de manuel <tt/exports/ qu'il faut lire au moins une fois dans sa vie. Il y a de meilleures façons de faire que de lister tous les hosts dans le fichier exports. Peuvent être autorisés à monter un système de fichiers NFS, des groupes réseaux (<em/net groups/) si vous utilisez NIS (ou NYS, auparavant connu sous le nom YP), des noms de domaines avec jokers et des sous réseaux IP. Mais il faudra vérifier qui pourrait obtenir un accès non autorisé au serveur avec ce type d'autorisations. Note : ce fichier exports n'utilise pas la même syntaxe que d'autres Unix. La plupart des autres Unix utilisent un format avec des options séparées par des virgules (,) et des listes d'hôtes séparées par des deux-points (:), à l'exception de Solaris 2 qui est complètement différent. Maintenant nous sommes prêts à lancer mountd (ou peut-être s'appelle-t-il <tt/rpc.mountd/), puis nfsd (qui s'appelle peut-être <tt/rpc.nfsd/). Ils liront tous deux le fichier exports. Si vous modifiez <tt>/etc/exports</tt>, vous devrez vous assurer que nfsd et mountd savent que le fichier a changé. Sur la plupart des systèmes Unix on peut le faire avec la commande <tt/exportfs -av/ (sauf pour Solaris 2 qui est complètement différent). Beaucoup de distributions Linux n'ont pas le programme exportfs. Si c'est le cas sur votre machine, vous pouvez installer ce script : <code> #!/bin/sh killall -HUP /usr/sbin/rpc.mountd killall -HUP /usr/sbin/rpc.nfsd echo re-exported file systems </code> Sauvez-le dans <tt>/usr/sbin/exportfs</tt> par exemple, et n'oubliez pas de lui appliquer <tt/chmod a+rx/. Désormais, chaque fois que vous changez votre fichier exports, lancez ensuite exportfs en root. Maintenant, vérifiez que mountd et nfsd fonctionnent correctement. D'abord avec <tt/rpcinfo -p/. Il devrait donner quelque chose du genre : <code> program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 745 mountd 100005 1 tcp 747 mountd 100003 2 udp 2049 nfs 100003 2 tcp 2049 nfs </code> On voit que le portmapper a annoncé ses services, de même que mountd et nfsd. Si vous obtenez : <tt/rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused/ ou quelque chose du style c'est que le portmapper ne tourne pas. Réglez ça. Si vous obtenez <tt/No remote programs registered/ alors soit le portmapper ne veut pas vous parler, soit quelque chose ne marche pas. Tuez nfsd, mountd et le portmapper et essayez de recommencer. Après avoir vérifié que le portmapper reporte les services vous pouvez vérifier aussi avec <tt/ps/. Le portmapper continuera à reporter les services même si les programmes qui les offrent ont crashé. Il vaut donc mieux vérifier par ps si quelque chose ne marche pas. Bien sur, vous devrez modifier vos fichiers systèmes rc pour lancer mountd et nfsd au démarrage de la même façon que le portmapper. Il y a de très fortes chances que les scripts existent déjà sur votre machine, vous aurez juste à décommenter les bonnes lignes ou les activer pour les bons <em/runlevels/ (pardon niveaux d'exécution) d'init. Quelques pages de manuel avec lesquelles vous devriez être familier : portmap, mountd, nfsd et exports. Bon, si vous avez tout fait exactement comme j'ai dit vous êtes prêts à enchaîner sur le client NFS. <sect>Installer un client NFS Tout d'abord il faudra compiler un noyau avec le système de fichiers NFS, soit compilé dans le noyau, soit disponible sous forme de module. Si vous n'avez encore jamais compilé un noyau vous aurez peut être besoin de consulter le HOWTO du noyau. Si vous utilisez une distribution très cool (comme Chapeau Rouge) et que vous n'avez jamais trifouillé le noyau (pas toucher toucher) il y a des chances que NFS soit automagiquement disponible. Vous pouvez maintenant, à l'invite (prompt) du root, entrer la commande <tt/mount/ appropriée et le système de fichiers apparaîtra. Continuons avec l'exemple de la section précédente, nous voulons monter <tt>/mn/eris/local</tt> depuis eris. La commande est : <code> mount -o rsize=1024, wsize=1024 eris:/mn/eris/local /mnt </code> (Nous reviendrons plus tard sur les options rsize et wsize.) Le système de fichiers est maintenant disponible sous /mnt et vous pouvez faire un cd sur lui, puis un ls et regarder les fichiers individuellement. Vous remarquerez que ce n'est pas aussi rapide qu'avec un système de fichiers local, mais beaucoup plus pratique que ftp. Si, au lieu de monter le système de fichiers, mount renvoie un message d'erreur comme <tt>mount: eris:/mn/eris/local failed, reason given by server: Permission denied</tt> alors le fichier exports est incorrect, ou vous avez oublié de lancer exportfs après avoir modifié le fichier exports. S'il dit <tt/mount: clntudp_ipdate: RPC: Program not registered/ cela signifie que nfsd ou mountd ne tourne pas sur le serveur. Pour vous débarrasser du système de fichiers, vous pouvez faire : <code> umount /mnt </code> Pour que le système monte automatiquement un système de fichiers NFS au démarrage, éditez <tt>/etc/fstab</tt> de la façon habituelle. Par exemple avec une ligne comme celle-ci : <code> # device mountpoint fs-type options dumps sfckorder ... eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024 0 0 ... </code> C'est presque tout ce qu'il y a à savoir. Vous pouvez jeter un coup d'oeil à la page de manuel <tt/nfs/. Continuons plize. <sect1>Optimisation de NFS Normalement, si les options rsize et wsize ne sont pas précisées, NFS écrira et lira par blocs de 4096 ou 8192 octets. Mais certaines combinaisons de noyau Linux et cartes réseau ne peuvent pas fonctionner avec ces valeurs, de plus, même si cela marche, cela peut ne pas être optimal du tout. Il nous faudra donc expérimenter et trouver les valeurs de rsize et wsize qui fonctionnent et donnent les transferts les plus rapides. Vous pouvez tester la vitesse de vos options avec des commandes simples. La commande mount ci-dessus ayant été exécutée, si vous avez l'accès en écriture sur le disque vous pouvez tester les performances en écriture séquentielle : <code> time dd if=/dev/zero of=/mnt/testfile bs=16k count=4096 </code> Ceci crée un fichier de 64 Mo ne contenant que des 0. Faites-le quelques (5-10?) fois et prenez la moyenne des temps. C'est le temps 'elapsed' ou 'wall clock' qui est le plus intéressant. Ensuite vous pouvez tester les performances en lecture en relisant le fichier : <code> time dd if=/mnt/testfile of=/dev/null bs=16k </code> faites le quelques fois et prenez la moyenne. Puis démontez (<tt/umount/) et remontez (<tt/mount/) avec des valeurs plus grandes pour rsize et wsize. Il vaut mieux prendre des multiples de 1024, et probablement pas plus grand que 16384 octets, car les gros blocs ralentissent les accès aléatoires. Immédiatement après avoir <em/remounté/ avec une taille supèrieure, <em/cédéez/ dans le système de fichiers et faites des trucs comme ls, explorez un peu pour vérifier que tout est bien normal. Si la valeur de rsize/wsize est trop grande, les symptômes sont <em/vraiment/ bizarres et pas évidents. Un symptôme typique est une liste de fichiers donnée par <tt/ls/ incomplète sans aucun message d'erreur. Ou la lecture de fichier qui échoue mystérieusement et sans message d'erreur. Après vous être assurés que les wsize/rsize choisis fonctionnent, vous pouvez faire les tests de rapidité. Différentes plateformes de serveur auront peut-être des tailles optimales différentes. SunOS et Solaris sont réputés pour être beaucoup plus rapides avec une taille de 4096 octets. Les noyaux Linux récents (depuis 1.3 ) font parfois des lectures anticipées (<em/read ahead/) pour des rsizes supérieurs ou égaux à la taille de page de la machine. Sur les CPU Untel la taille de la page est de 4096 octets. La lecture anticipée augmentera <em/sensiblement/ les performances en lecture. Sur une machine Untel on devrait donc choisir un rsize de 4096 si c'est possible. Un truc pour augmenter les performances d'écriture de NFS est d'invalider les écritures synchrones sur le serveur. Les specifications de NFS disent que les requêtes d'écriture de NFS ne doivent pas être considérées comme terminées avant que les données ne soient sur un medium non versatile (normalement le disque). Ceci réduit les performances à l'écriture, les écritures asynchrones sont plus rapides. Le nfsd Linux ne fait pas d'écritures synchrones car l'implémentation du système de fichiers ne s'y prête pas, mais sur les serveurs non-Linux vous pouvez augmenter les performances de cette façon dans votre fichier exports : <code> /dir -async, access=linuxbox </code> ou quelque chose du genre. Référez-vous à la page de manuel exports de la machine concernée. <sect1>Autres options Il y a trois comportements principaux des clients NFS en cas de chute du serveur qui sont spécifiés par les options de montage : <descrip> <tag/soft/ Le client NFS renverra une erreur au processus concerné si après quelques essais le serveur NFS persiste à ne pas répondre. Si vous voulez utiliser cette option, vous devez vérifier que votre logiciel la gère correctement. Je ne recommande pas ce réglage. <tag/hard/ Le client NFS réessaiera infiniment jusqu'à ce qu'il soit tué. Les opérations reprendront normalement si le serveur NFS se rétablit ou redémarre. Le client ne pourra pas être interrompu ou tué. <tag/hard,intr/ Comme hard, mais Ctrl-C tuera le processus bloqué. Dans quelques cas, notament un disque /usr/spool/mail monté par NFS cela ne changera rien car le shell ignore le Ctrl-C quand il teste si vous avez du mail. Je recommande cette option pour <bf/tous/ les systèmes de fichiers NFS, y compris le <em/spool/ du mail. </descrip> Reprenant l'exemple précédent, supposons que vous avez trouvé 4096 octets comme taille optimale de lecture/écriture, votre entrée fstab est maintenant : <code> # device mountpoint fs-type options dumps sfckorder ... eris:/mn/eris/local /mnt nfs rsize=4096,wsize=4096,hard,intr 0 0 ... </code> <sect>NFS et la sécurité Je ne suis en aucun cas un expert en sécurité informatique. Mais j'ai traîné dans le secteur et j'ai un <em/petit/ conseil pour ceux qui se préoccupent de la sécurité. Mais attention. Ce n'est pas absolument pas une liste complète des problèmes liés à NFS et si vous pensez être en sécurité une fois que vous avez lu et mis en pratique tout ceci alors j'ai un pilier de pont (presque neuf) à vous vendre. Cette section n'a probablement pas d'intérêt si vous êtes sur un réseau <em/fermé/ où vous avez confiance en tous les utilisateurs, et que personne en qui vous n'avez pas confiance ne peut obtenir un accès sur les machines du réseau. I.e., il ne devrait y avoir aucun moyen de se connecter à votre réseau depuis l'extérieur et il ne devrait être relié à aucun autre réseau où vous n'avez pas confiance en tous les utilisateurs et en sa sécurité. Vous pensez que je suis parano ? Je ne suis pas du tout parano. C'est un conseil de sécurité <em/de base/. Et rappelez-vous que c'est juste le commencement. Un site <em/sûr/ nécessite un administrateur consciencieux et bien informé qui sait où trouver l'information sur les problèmes de sécurité existants ou potentiels. Un problème de base de NFS est que le client, si on ne lui demande pas le contraire, fera confiance au serveur NFS et vice-versa. Ça peut être mauvais. Cela signifie que si le compte root du serveur est cassé (<em/broken into/) il peut être très facile de casser le compte root du client. Et vice versa. Il y a quelques moyens de gérer ce problème sur lesquels nous reviendrons. Les documents consultatifs (<em/advisories/) du CERT sur NFS sont une bonne source d'information, la plupart des problèmes (et des solutions) évoquées ci-dessous sont traités dans ces documents. Voyez ftp.cert.orf/01-README pour une liste à jour. En voici quelques-uns liés à NFS (il n'y a pas à ma connaissance de version française) : <code> CA-91:21.SunOS.NFS.Jumbo.and.fsirand 12/06/91 Vulnerabilities concerning Sun Microsystems, Inc. (Sun) Network File System (NFS) and the fsirand program. These vulnerabilities affect SunOS versions 4.1.1, 4.1, and 4.0.3 on all architectures. Patches are available for SunOS 4.1.1. An initial patch for SunOS 4.1 NFS is also available. Sun will be providing complete patches for SunOS 4.1 and SunOS 4.0.3 at a later date. CA-94:15.NFS.Vulnerabilities 12/19/94 This advisory describes security measures to guard against several vulnerabilities in the Network File System (NFS). The advisory was prompted by an increase in root compromises by intruders using tools to exploit the vulnerabilities. CA-96.08.pcnfsd 04/18/96 This advisory describes a vulnerability in the pcnfsd program (also known as rpc.pcnfsd). A patch is included. </code> <sect1>Sécurité du client Du côté client il y a quelques options de mount qui permettent de ne pas faire trop confiance au serveur. L'option <tt/nosuid/ interdit le démarrage de programmes suid du système de fichiers NFS. C'est une option à utiliser systématiquement, car elle empêche le root du serveur de créer un fichier suid sur le système de fichiers NFS, puis de se loger dans le client en utilisateur et de lancer le programme suid pour devenir root sur le client. Il est aussi possible d'interdire l'exécution des fichiers du système de fichiers NFS avec l'option <tt/noexec/. Mais ceci est beaucoup moins utile que <tt/nosuid/ car le système de fichiers contiendra très probablement au moins <em/quelques/ scripts ou programmes à exécuter. Ces options se rentrent dans la colonne d'options, avec <tt/wsize/ et <tt/rsize/, séparées par des virgules. <sect1>Sécurité du serveur : nfsd Du côté serveur on peut ne pas faire confiance au root du client, avec l'option <tt/root_squash/ (rembarrage du root :-) dans le fichier exports : <code> /mn/eris/local apollon(rw, root_squash) </code> Dans ce cas, si un utilisateur du client avec l'UID 0 essaye d'accéder (en lecture, écriture ou effacement) au système de fichiers, le serveur remplace l'UID par celui de l'utilisateur 'nobody' du serveur. Ceci signifie que l'utilisateur root du client ne peut accéder/modifier les fichiers du serveur que seul le root du serveur peut accéder/modifier. C'est bien, et vous aurez probablement à utiliser cette option sur tous les systèmes de fichiers que vous exportez. J'en entends un qui me dit : "Mais l'utilisateur root du client peut toujours utiliser 'su' pour devenir n'importe qui et accéder à ses fichiers !" Et là je réponds : "Oui, c'est comme ça, c'est Unix." Ceci a une conséquence importante : tous les fichiers et binaires importants devraient appartenir à <tt/root/, et pas <tt/bin/ ou un compte autre que root, car le seul compte auquel le root du client ne peut pas accéder est le compte root du serveur. Plusieurs autres options permettant de ne pas faire confiance à qui ne vous plait pas sont énumérées dans la page de manuel nfsd. Il y a aussi des options pour rembarrer (<em/to squash/) des intervalles d'UID ou GID. Il est important aussi de s'assurer que nfsd vérifie que toutes les requêtes viennent d'un port privilégié. S'il accepte les requêtes de n'importe quel port du client, un utilisateur simple peut exécuter un programme qu'il est facile de se procurer sur l'Internet. Il parle le protocole NFS et pourra prétendre être n'importe qui et être cru. Ça fait peur hein ? Le nfsd Linux effectue cette vérification par défaut, sur d'autres systèmes d'exploitation il faut la valider. Ça devrait être décrit dans la page man de ce système. Autre chose. N'exportez jamais un système de fichiers vers 'localhost' ou 127.0.0.1. Croyez-moi. <sect1>Sécurité du serveur : le portmapper Le portmapper de base, en combinaison avec nfsd présente un problème de conception qui rend possible de récupérer les fichiers d'un serveur NFS sans avoir aucun privilège. Heureusement le portmapper de Linux est relativement sûr vis à vis de cette attaque, et peut être sécurisé en configurant les listes d'accès au moyen de deux fichiers. Tout d'abord, éditons <tt>/etc/hosts.deny</tt>. Il devrait contenir la ligne: <code> portmap: ALL </code> qui refusera l'accès à <em/quiconque/. C'est peut être un peu excessif, nous ré-ouvrons donc un peu l'accès en éditant le fichier <tt>/etc/hosts.allow</tt>. Mais il faut d'abord savoir ce qu'on va y mettre. À la base, il devrait contenir les noms de toutes les machines qui doivent avoir accès à votre portmapper. Sur le système Linux moyen  il y a très peu de machines qui ont une bonne raison de demander cet accès. Le portmapper administre nfsd, mountd, ypbind/ypserv, pcnfsd et les services "en r" comme ruptime et rusers. Parmis ceux-ci, seuls nfsd, mountd, ypbind/ypserv et peut-être pcnfsd ont de l'importance. Toutes les machines qui ont besoin d'accéder à ces services sur votre machine devraient y être autorisées. Disons que votre machine est 129.240.223.254 et que tout ce qui vit sur le sous réseau 129.240.223.0 doit pourvoir y accéder (si ceci n'est pas clair pour vous, voyez le HOWTO réseau). On écrit : <code> portmap: 129.240.223.0/255.255.255.0 </code> dans <tt/hosts.allow/. C'est l'adresse de réseau que vous donnez aussi à la commande <tt/route/ et le masque de réseau que vous donnez à <tt/ifconfig/. Pour le périférique <tt/eth0/ sur cette machine <tt/ifconfig/ devrait donner : <code> ... eth0 Link encap:10Mbps Ethernet HWaddr 00:60:8C:96:D5:56 inet addr:129.240.223.254 Bcast:129.240.223.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:360315 errors:0 dropped:0 overruns:0 TX packets:179274 errors:0 dropped:0 overruns:0 Interrupt:10 Base address:0x320 ... </code> et <tt/netstat -rn/ devrait donner : <code> Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface ... 129.240.223.0 0.0.0.0 255.255.255.0 U 0 0 174412 eth0 ... </code> (Adresse réseau dans la première colonne). Les fichiers <tt/hosts.deny/ et <tt/hosts.allow/ sont décrits dans les pages de manuel de mêmes noms. <bf/IMPORTANT/ : ne <em/rien/ mettre d'autre que des adresses IP (numériques) dans les lignes portmap de ces fichiers. Les <em/host name lookup/ (recherche d'adresse IP (numérique) à partir de l'adresse symbolique) peuvent indirectement déclencher une activité portmap qui déclenchera un <em/host name lookup/ qui déclenchera... Ceci fait, votre serveur devrait être un peu plus solide. Le dernier problème (mais oui !) est que quelqu'un casse le compte root (ou boute MS-DOS) sur une machine de confiance et utilise ce privilège pour envoyer des requêtes depuis un port sûr en se faisant passer pour n'importe quel utilisateur. <sect1>NFS et les coupent-feu (firewalls) C'est une très bonne idée de <em/firewaller/ les ports NFS et portmap dans votre routeur ou firewall. nfsd utilise le port 2049, que ce soit avec tcp ou udp. Le portmapper est au port 749 (tcp et udp) et mountd aux port 745 et 747 (tcp et udp). Vérifiez les ports avec la commande <tt/rpcinfo -p/. Si au contraire vous voulez que NFS traverse un firewall, il existe des options sur les nfsd et mountd récents pour leur spécifier le port à utiliser. Vous pouvez donc choisir un port qui ne soit pas bloqué par le firewall. <sect1>Résumé Si vous configurez correctement votre installation portmapper/NFS avec hosts.allow/deny, root_squash, nosuid et les ports privilégiés, vous évitez beaucoup des bogues connues de NFS et pouvez presque vous sentir en sécurité au moins pour <em/ça/. Mais de toutes façons : quand un intrus obtient l'accès à votre réseau, il/elle peut faire apparaître des commandes bizarres dans votre .forward ou dans votre fichier mailbox quand <tt>/home</tt> ou <tt>/var/spool/mail</tt> sont montés par NFS. Pour la même raison, vous ne devriez jamais accéder à votre clé privée PGP par NFS. Ou au moins vous devez savoir quel est le risque. Et maintenant vous savez un peu. NFS et le portmapper constituent un système complexe et il n'est donc pas totalement exclu que de nouvelles bogues soient découvertes, soit dans la conception soit dans l'implémentation que nous utilisons. Il pourrait même y avoir des défauts de sécurité connus, que quelqu'un utilise. Mais c'est la vie. Pour vous tenir au courant, vous devriez au moins lire les forums comp.os.linux.announce et comp.security.announce comme minimum absolu (en français, consultez fr.comp.os.linux.annonces ). <sect>FAQ Voici la section FAQ. La majeure partie en a été écrite par Alan Cox. <enum> <item> Quand j'essaye de monter le système de fichiers j'obtiens <tscreen><verb> can't register with portmap: system error on send </verb></tscreen> Vous utilisez probablement un système Caldera. Il y a une bogue dans les scripts rc. Contactez Caldera pour obtenir la solution. <item> Pourquoi ne puis-je pas exécuter un fichier après l'avoir copié sur le serveur NFS ? La raison est que nfsd cache les manipulation de fichiers pour des raisons de performances (rappelons qu'il fonctionne dans l'espace utilisateur). Ainsi, après une écriture le fichier peut ne pas être fermé tout de suite, et tant qu'il est ouvert le noyau ne vous autorisera pas à l'exécuter. Les nfsd plus récents que le printemps 95 (hum...) ferment les fichiers ouverts après quelques secondes, les plus vieux pouvaient ne pas les relâcher avant plusieurs jours... <item> Mes fichiers NFS sont tous en lecture seule. Le serveur NFS Linux est par défaut en lecture seule. RTFM les pages de manuel exports et nfsd. Vous devrez modifier <tt>/etc/exports</tt>. <item> Je monte depuis un serveur NFS Linux, il marche et pourtant je ne peux pas lire ou écrire de fichiers. Sur les anciennes versions de Linux il faut monter un serveur NFS avec <tt/rsize=1024, wsize=1024/. <item> Je monte depuis un serveur NFS Linux avec une taille de bloc comprise entre 3500 et 4000 et Linux crashe régulièrement. Ne faites pas ça. (!) <item> Est-ce que Linux peut utiliser NFS sur TCP ? Non, pas pour le moment. <item> J'ai des tonnes d'erreurs bizarres en essayant de monter la machine depuis un serveur Linux. Assurez-vous que vos utilisateurs sont dans 8 groupes au maximum. C'est une limitation des vieux serveurs. <item> Quand je redémarre ma machine elle se bloque parfois en essayant de démonter un serveur NFS bloqué (<em/hung/). Ne démontez <bf/pas/ les serveurs NFS en redémarrant ou arrêtant la machine, ça ne créera pas de problèmes si vous ne le faites pas. La commande est <tt/umount -avt nonfs/. <item> Les clients NFS Linux sont très lents quand ils écrivent sur des systèmes Sun ou BSD. Normalement les écritures NFS sont synchrones (vous pouvez le désactiver si vous ne craignez pas de perdre des données). Les noyaux dérivés de BSD ont tendance à ne pas savoir travailler avec des petits blocs. Ainsi quand vous écrivez 4K de données depuis un client linux dans des paquets de 1K, BSD fait ceci : <tscreen><verb> lit une page de 4K traite 1K écrit 4K sur le disque lit une page de 4K traite 1K écrit 4K sur le disque ... </verb></tscreen> De meilleurs systèmes n'ont pas ce problème. Mais le client Linux est assez lent de toute façon. <item> J'ai entendu dire que NFS n'est pas sûr, c'est vrai ? Oui, absolument. Utiliser NFS dans un environnement incontrôlé est un peu comme laisser votre porte ouverte, peindre 'en vacances' sur votre maison et envoyer des cartes à tous les criminels connus... Dans un environnement sûr ou quand vous pouvez récupérer vos données après une erreur c'est utilisable. Le pire que quelqu'un peut faire facilement est d'altérer tous les fichiers du disque NFS et crasher la machine. Tant que vous ne montez pas vos systèmes de fichiers NFS en rw vous devriez être légèrement en sécurité. <item> Pourquoi utilisons-nous NFS alors ? Parce que c'est le seul protocole de partage de fichiers supporté uniformément par Unix. Et parce qu'il marche, surtout. <item> Que faire quand quelque chose bloque suite à une chute du serveur ? Voir la section 4.2. </enum> <sect>PC-NFS Il y a certaines choses qu'il vaut mieux ne pas documenter :-). Mais si vous voulez utiliser PC-NFS, il faut lancer pcnfsd. Bonne chance. Je sais, c'est pas très sympa, mais je ne connais pas bien PC NFS. Si vous oui, merci de me contacter et on pourra peut-être mettre quelque chose sur PC NFS ici. </article>