Initié en 2001 par l'Université du Michigan, développé et fiabilisé par NetApp et Bull, en version 4, ce protocole de partage de données a été entièrement repensé et ré-écrit pour le partage au travers d'Internet.
NFSv4 est également conçu pour pallier les lacunes des versions précédentes et se pose en successeur et en concurrent de Samba, NFSv3 ou de AFS dont il s'inspire.
Par rapport à ses prédécesseurs, NFSv4 embarque de nombreuses avancées telles que :
- une technologie de cache agressive (délégation)
- Le regroupement des requêtes réseau (Compound request)
- La sécurisation négociée et le chiffrement des données : Kerberos 5, Certificats (SPKM), Clefs publiques/privées (LIPKEY)
- La capacité pour les clients de maintenir des sessions ou de les récupérer malgré un crash serveur ou une panne du réseau
- La possibilité (à terme) de rediriger la charge de serveurs saturés vers un autre serveur, de manière transparente pour les clients
- Le support d'attributs fichier nommés par l'utilisateur (ex. un attribut 'photos')
Disponible pour la plupart des Unix (dont Linux), mais également pour MS-Windows, ce nouveau système de fichier réseau a une vocation industrielle. Il pourrait facilement être utilisé par des particuliers : des versions gratuites et simples à employer existent pour Linux et BSD et la sécurisation forte des échanges mise en oeuvre par NFSv4 protégera efficacement leurs échanges sur le réseau.
![[en]](../images/en.png)
Le projet de référence pour linux (1751 hits)-
Fiabilisation du projet (567 hits)
-
Guide de migration NFSv3 vers NFSv4 (1275 hits)
-
Suivi développements client NFS (634 hits)
-
Suivi développements serveur NFS (495 hits)
> Lire la dépêche (80 commentaires, moyenne: 3,2).
Vous avez demandé le commentaire #671779.
Run by 
Cette page a été générée par Templeet en 0.1029s (dont 0.0099 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Numéro d'utiisateur
Si je me trompe pas, NFS, on peut pas mêtre d'identifiant, il faut avoir le même numéro d'utilisateur. Ce qui me semble pas pratique pour un partage simple des fichiers.
Ce sera pareil avec la version 4 ?
[^]Re: Numéro d'utiisateur
oui c'etait le cas.
Et je crois bien que ce sera possible de faire les choses differement avec cette nouvelle version, d'apres ce que j'en avais lu (et d'apres ma memoire :)
[^]Re: Numéro d'utiisateur
C'est la question que je me pose aussi. Si on a pas la possibilité de gérer des utilisateurs en dehors de ceux du système, ou au moins de faire un mapping entre les utilisateurs coté client et ceux coté serveur, samba/cifs sera toujours mieux...
Il serait bien aussi qu'un simple utilisateur puisse monter ou utiliser un espace distant sans être obliger d'être root. Un login/mot de passe/certificat/jeton Kerberos pour se faire reconnaître du serveur devrait suffire.
[^]Re: Numéro d'utiisateur
En regardant le tutorial, ça marche comme en V3. Il faut une base d'utilisateur commune au serveur et au client, NIS ou LDAP...
[^]Re: Numéro d'utiisateur
Tu peux aussi indiquer au serveur NFS un mapping entre telle UID et telle autre UID, où donner à tous les utilisateurs un même UID (un peu comme un mode anonyme en FTP finalement).
[^]Re: Numéro d'utiisateur
ça a l'air compliqué, je me dis, autant utiliser samba, quand on comprend pas tout ça ....
[^]Re: Numéro d'utiisateur
NFSv4 est prévu pour internet, et évidement sur internet il difficile de prévoir quel UID sera utilisé par un client sur une machine de l'autre côté de la planète...
Donc, nfsv4 prévoit un ID mapper qui permet de faire des correspondances entre les uid/gid des clients et ceux du serveur...
Pour ceux qui ont un LAN avec quelques machines et pour qui ce mécanisme est inutile, NFSv4 supporte (évidemment) et dans la configuration par défaut la correspondance : uid client = uid serveur... sauf pour l'utilisateur root pour des raisons évidentes de sécurité (root client = nobody serveur, par défaut).
En bref, la configuration par défaut offre un fonctionnement proche de SAMBA, avec des performances et une sécurisation plus efficace; et tout est prévu pour aller plus loin, beaucoup plus loin.
C'est une avancée importante de pouvoir gérer correctement les uid/gid sur NFsv4 par rapport à NFSv3.
L'idmapper s'interface avec LDAP et NIS et permet des déploiements plus complexes (dans le style active directory, par exemple)
[^]Re: Numéro d'utiisateur
Il y a des trucs super avec Samba. Par exemple ;
- le root d'une machine n'est pas capable de réellement prendre l'identité d'une autre personne. Faire sous root "su - toto" permettra d'avoir un shell sous toto mais aucunement d'avoir accès aux données de toto. Avec NFS, si ! Or comment voulez faire confiance a une tentacule de PC distribué sur le net dont vous ne seriez pas sur des root...
- j'adore la possibilité de pouvoir lancer des scripts via les hooks "root pre exec...". Je trouve cela super souple. Je crée ainsi pas mal de script .bat à chaud en fonction de la personne mais aussi de la machine. OK, on doit pouvoir faire cela avec apache2 et j'envisage de transférer une partie de mes scripts utilisant un transport CIF vers du transport http, mais bon, c'est pratique ces hooks.
OK, samba a aussi plein de défauts. Pas de point de montage partagé entre utlisateurs, un protocole qui fait tout et n'importe quoi (partage de fichier, impression...). Ce serait bien de pouvoir avoir un paquet samba qui n'ai pas le code concernant l'impression par exemple.
[^]Re: Numéro d'utiisateur
"le root d'une machine n'est pas capable de réellement prendre l'identité d'une autre personne."(sous samba) "Avec NFS, si !"
j'ai gentoo...ca resemble a bsd donc je sait pas pour les autres distribs
dans /etc/exports qui est le fichier de configuration ou tout est stoque pour le serveur nfs...(repertoire,ip,options) ba dans les options de configuration t'as des option pouvant empecher ca
man exports pour plus d'info
[^]Re: Numéro d'utiisateur
C'est surout un pb de mapping : vu qu'il y a pas d'authentification NFS n'a pas moyen de savoir si tu dis vraiement qui t'es.
avec /etc/exportso n peut mapper le root en anonymous, mais j'ai pas souvenir qu'on puisse faire plus complexe...
[^]Re: Numéro d'utiisateur
J'ai l'impression que NFS, c'est probablement une bonne chose pour des gros server qui se font confiance entre eux, mais en aucun cas pour des particuliers.
Moi je me sert de samba, alors que je sait même pas mon uid ni mon gid, ni ce que c'est un mapping de uid/gid
c'est ça qui est bien avec samba. c'est a peut près aussi facile d'emploit qu'un ftp avec des aventages en plus.
[^]Re: Numéro d'utiisateur
C'est tout à fait la philosophie des auteurs du protocole Smb : faire un truc simple, ou y a qu'a cliquer pour le configurer et ou faut surtout pas comprendre comment ça marche. Et tant pis si c'est tout pourris, ça fait ramer les réseau etc.
Non pas que je pense que des logiciels simples à utiliser soient néfastes, au contraire. Simplement, ce type de discours ("je me fous de comment ça marche du moment qua j'arrive à le faire marcher en 5 minutes") était exclusivement tenu par des Windowsiens, auxquels ont répondait qu'un newbie qui comprend rien à ce qu'il fait est dangereux et que sous Linux on est obligé de comprendre un minumum avant de faire n'importe quoi.
De fait, les légendaires problèmes de sécurité de Windows furent longtemps majoritairement des problèmes d'administrateurs amateurs qui faisaient n'importe quoi (pourvu que ça marche).
En prendrait-on la direction sous *nix ?
[^]Re: Numéro d'utiisateur
Il suffit de voir cette daube de gconf qui ne sers à rien ...
On peux cependant reprendre dans SMB ce qui est bien. Par exemple, l'authentification des utilisateurs et virer ce qui est pourris (le partage par n'importe qui n'importe comment, le partage d'impression, les élections pour être master du voisinage réseau, le mélange avec les RPC...)
[^]Re: Numéro d'utiisateur
Je comprend pas le premier point... tu fais forcément confiance au root où se trouve tes données, puisque tu mets tes données sur son PC/serveur... J'arrive pas à me représenter un cas concret illustrant ce que tu dis. Je suis toto sur la machine A, j'accède à mes données en tant que toto sur la machine B, donc, oui, root de la machine B peut accéder à mes données, mais c'est tout, aucun autre root ne le peux.
Ce qui est un peu plus dangereux, c'est NIS : NIS peut dire "si tu es root sur A, c'est comme si tu étais root sur B" (mais les machines A et B doivent faire partie du réseau NIS). C'est pourquoi root est généralement une exception dans la base NIS : c'est le seul utilisateur qui n'est pas dedans (si l'admin a bien configuré son truc).
En plus, tu sembles dire que samba a des avantages sur NFS, mais je me représente encore moins lesquels (à part le multi-plate-forme évidemment). Samba est hyper lent pour le transfert de fichiers.
[^]Re: Numéro d'utiisateur
Je connais un peu NFS et Samba ainsi que NIS. Je les utilise tous les trois tous les jours ;-)
Les fichiers de toto sont une la machine A, tu te logues sur la machine B, tu passes en root et tu fais su - toto. Tu as alors acces a tous les fichiers de toto sur la machine A alors que tu es sur la machine B !
Avec Samba, cela ne marche pas car même si tu devient toto sur la machine B, cela ne te donne pas le droit de lire les fichiers sur la machine A. C'est tout.
Au niveau performance, je suis d'accord et j'utilise nfs en local entre mes machines UNIX dont je controle le root !
C'est pour cela qu'avoir un NFS qui tient sur internet me parait à la fois mieux (car ca ira aussi mieux en local) mais je ne vois pas bien comment je pourrais avoir confiance en des machines distribués sur le net et dont je ne maitrise pas le root.
Au niveau NIS, tu gères qui est dans la base NIS et il n'y a pas que le root qui est exclus ! En pratique, tu ne met que la plage des uid de tes utilisateurs. NIS n'est pas super sécurisé mais combien de personne tourne avec un ldap sans ssl ! D'un point de vue sécurité, ldap sans ssl n'est pas franchement mieux que nis. Il suffit de mettre un poste client de l'annuaire et de faire un "getent password" pour s'en rendre compte. La aussi, il faut maitriser les root locaux que le ldap soit avec ssl ou sans ssl.
Question : comment maitrises tu le root des portables qui passe leur temps a voyager ?
J'espère avoir été plus clair ;-)
[^]Re: Numéro d'utiisateur
La réponse s'appelle Kerberos :)
(En réalité les 3 protocoles de sécurité proposés)
[^]Re: Numéro d'utiisateur
> Les fichiers de toto sont une la machine A, tu te logues sur la machine B, tu passes en root et tu fais su - toto. Tu as alors acces a tous les fichiers de toto sur la machine A alors que tu es sur la machine B !
Il faut que A partage ses fichiers à B pour ça, donc que le root@A fasse confiance au root@B (au moins partiellement, genre partage en lecture seule).
[^]Re: Numéro d'utiisateur
C'est justement le problème !
La machine A doit rendre accessible des fichiers pour toto qui travaille sur la machine B en lecture ecriture.
A partir de ce moment là, il faut avoir le controle du root de la machine B ce qui est difficile pour un protocole qui irait sur internet parce que les machines pourraient etre distantes de pas mal de bornes.
Avec un partage de type samba, il n'y a pas ce problème... Mais cela a aussi des inconvénients. Par exemple avec NFS, tu te logues et avec l'automounteur, tu as toutes tes données en lecture écriture (enfin, avec le module pam pmount, on peux faire a peu près pareil avec samba). L'autre avantage est de pouvoir mutualiser les points de montages et les requètes sur le serveur nfs entre les utilisateurs.
Dans les laboratoires de recherche, on a de plus en plus affaire a du nomadisme. NFSv4 ne semble pas pouvoir répondre à cette problématique.
[^]Re: Numéro d'utiisateur
Si, il y répond complètement et a été conçu dans cette optique. NFSv4 se veut un concurent de SAMBA (entre autre) et donc permet _au minimum_ d'imiter le fonctionnement de SAMBA.
NFSv4 peut être associé à :
IDMapper ou/et LDAP ou/et Kerberos.
L'utilisation de Kerberos délivre un jeton de manière indépendante de l'UID utilisé, et permet le montage avec les droits correspondant.
Donc, à la base peux avoir un montage indépendament de la machine utilisée avec des droits corrects.
Ajoute LDAP et tu n'as même pas besoin de spécifier quel répertoire tu dois monter pour obtenir tes données.
Je ne comprends pas où tu vois un problème?
[^]Re: Numéro d'utiisateur
Je précise que je n'ai jamais utilisé NFSv4. Donc je navigue a vue. Je ne suis pas là pour descendre NFS que j'utilise tous les jours et que je trouve parfois bien plus pratique que Samba.
Pour moi, d'après ce que j'ai compris, NFS identifie les machines et non les personnes. Dans la version 4, c'est nettement supérieur à ce qui se faisait dans la version 3 (en gros, les netgroup).
Le problème d'après moi est que si tu authorises une personne a accéder à un serveur NFS(v4) sur sa machine avec son compte, alors si elle a le mot de passe root, elle peux accéder aux données concernant les autres personnes qui aurait accès à cette même machine. Chose non possible avec Samba.
[^]Re: Numéro d'utiisateur
"Le problème d'après moi est que si tu authorises une personne a accéder à un serveur NFS(v4) sur sa machine avec son compte, alors si elle a le mot de passe root, elle peux accéder aux données concernant les autres personnes qui aurait accès à cette même machine. Chose non possible avec Samba."
Ce n'est pas le cas. Ce n'est d'ailleurs pas le cas non plus avec NFSv3 si tu utilises l'option root_squash (Option passée dans la configuration par défaut)
Dans la version 4, c'est le rôle de l'IDMapper de faire correspondres les identifiants entre client et serveurs, et les droits correspondants sont appliqués par NFS.
Si tu utilises un protocole de sécurité tel que Kerberos lié à LDAP, alors le risque est nul, même si tu te loggue sur une machine qui n'est pas la tienne, et que tu réalise un montage.
Tu as un message privé...
[^]Re: Numéro d'utiisateur
> Tu as un message privé...
OK, je te repond la dessus tout a l'heure.
Sinon, root_squash ou pas, ca ne change pas grand chose.
Je suis root sur une machine, je fais su - toto et je prends l'identité de toto et peux alors lire les fichiers de toto sur le serveur.
Le problème est que sur un portable qui se balade, la personne a le mot de passe root DONC peut prendre l'identité de n'importe quel compte accessible sur cette machine. Dès que les machines se font confiances, cette personne a donc accès a tous les fichiers exportés sur des partages NFS, quel que soit les droits posés dessus... CQFD.
[^]Re: Numéro d'utiisateur
En même temps, le mot de passe root donne accès à tous les mots des utilisateurs (par cassage ou par écoute clavier...), que l'on utilise du NFS, du SMB, du FTP ou du SSH...
[^]Re: Numéro d'utiisateur
Je suis d'accord, mais je pense par exemple à un portable en libre service utilisé par pleins de personnes mais pas en même temps.
Il est clair que sur une machine réellement multi-utilisateurs, le mot de passe root ne doit pas être diffuser. C'est rarement le cas des portables or ce sont les portables qui posent des problèmes d'administration aujourd'hui.
[^]Re: Numéro d'utiisateur
Euh? Pourquoi les utilisateurs d'un portable en libre service devraient avoir le mot de passe root?
[^]Re: Numéro d'utiisateur
Si le portable voyage beaucoup, il y a des cas où on est obligé de le donner a distance...
Sinon, a moins de verouiller complètement dès le BIOS, on sais ca que vaut réellement un mot de passe root ! C'est très facile a casser sur une machine.
Et même en verouillant le BIOS, il suffit de demonter le disque dur et de le monter sur une autre machine pour le changer. C'est vachement dur (en général une vis a déviser).
Bref, personnellement, je n'ai pas confiance dans les portables qui voyagent...
Mais depuis que je sais que NFSv4 authentifie les personnes et pas seulement les machines comme sous NFSv3, le problème du root est bien moins crucial.
[^]Re: Numéro d'utiisateur
Et pourquoi pas ?
C'est le meme problème avec un portable personnel. C'est pratique de pouvoir donner le pass root à l'utilisateur du portable (de toute facon, il n'aura pas trop de mal à le récuperer lui meme avec un accès physique à la machine). Le problème avec NFSv3, c'est qu'en autorisant sa machine à se connecter au serveur NFS, on lui autorise l'accès à tous les fichiers des autres utilisateurs en meme temps, car la verification des permissions sur les fichiers est effectuée par la machine cliente (sur laquelle l'utilateur est root), et non pas sur le serveur NFS. Il lui suffit donc d'un 'su - ptramo' pour acceder aux fichiers de Pierre Tramo (le très celebre J2EE Lead Architect).
[^]Re: Numéro d'utiisateur
Avec samba aussi il faut faire un maping d'UID...
[^]Re: Numéro d'utiisateur
Depuis NFSv4, on peut utiliser Kerberos.
En fait on peut utiliser Kerberos pour à peu près toutes les taches d'authentification maintenant: se loguer en SSH, se loguer en shell avec PAM, utiliser un proxy socks v5...