Résumé

  • Le client décrit par le RFC 2054 essayait TCP sur le port 2049, puis UDP 2049, supposait NFSv3 et le descripteur public de longueur nulle, avant de se replier selon l’erreur vers v2, PORTMAP et MOUNT.
  • Le descripteur public fournissait une référence initiale. Il ne prouvait ni l’identité du serveur, ni l’autorisation d’un export, ni la sûreté du chemin, ni la réussite d’une lecture.
  • La résolution de plusieurs composants en un seul LOOKUP conservait des conditions propres aux chemins canoniques ou natifs, aux liens symboliques et au franchissement de systèmes de fichiers.

Remplacer une formalité par une hypothèse contrôlée

Dans la voie classique, le service de liaison sur le port 111 indiquait où se trouvait un programme RPC. Le service MOUNT n’ayant pas de port fixe, le client demandait sa localisation à PORTMAP, puis envoyait MOUNTPROC_MNT pour obtenir le premier descripteur correspondant à un chemin exporté. NFS pouvait ensuite opérer à partir de cette référence opaque créée par le serveur.

Cette séparation distribuait correctement les rôles, mais elle coûtait des allers-retours et exposait un port MOUNT dynamique aux contraintes des pare-feu et des mandataires. Le RFC 2054 observa que les serveurs NFS réutilisaient généralement le port 2049 après redémarrage. Il transforma cette régularité en pari réversible : tenter TCP 2049, puis UDP 2049 si la connexion est refusée, et ne consulter PORTMAP que si aucun des deux transports ne répond.

Une réponse sur 2049 ne valide donc pas toute la chaîne. Elle clôt uniquement la question « un service a-t-il répondu ici par ce transport ? ». La version du programme, la sémantique WebNFS, l’identité et les droits restent ouvertes.

Chaque erreur renvoie à une hypothèse différente

Après le contact, le client suppose NFSv3 et envoie normalement un LOOKUP avec le descripteur public v3. L’erreur RPC PROG_MISMATCH contredit la version, non l’existence du serveur : le client recommence avec NFSv2 et le descripteur public v2.

Les erreurs NFS3ERR_STALE, NFS3ERR_INVAL ou NFS3ERR_BADHANDLE contredisent autre chose : le serveur ne reconnaît pas le descripteur public. Le client doit alors retrouver MOUNT au moyen de PORTMAP et obtenir un descripteur initial traditionnel. Confondre refus TCP, silence UDP, incompatibilité de version et rejet du descripteur sous une seule étiquette ferait perdre la précision même du mécanisme de repli.

Zéro ne contenait ni identité ni permission

Le descripteur public v2 est composé de 32 octets nuls ; celui de v3 a une longueur nulle. Contrairement aux descripteurs ordinaires, il n’est pas produit pour identifier un fichier particulier. Il invoque une sémantique réservée, depuis un emplacement choisi par l’administrateur.

Le mot « public » n’abolit pas l’export. Le RFC 2055 exige une erreur lorsque la destination n’appartient pas à un système de fichiers exporté. Il distingue aussi les serveurs qui vérifient l’accès lors de MOUNT de ceux qui le vérifient à chaque requête NFS. Les premiers ne peuvent pas autoriser automatiquement un autre export atteint en franchissant un point de montage, même si cet export existe. Le descripteur peut ouvrir la résolution ; seul le contrôle d’accès peut ouvrir la ressource.

Un LOOKUP plus dense, pas une preuve plus large

Un LOOKUP ordinaire résout un composant par rapport à un descripteur de répertoire. WebNFS permettait, uniquement depuis le descripteur public, de soumettre a/b/c en une seule requête. Le gain portait sur le nombre de messages.

La chaîne restait gouvernée par une grammaire. Un chemin commençant par un caractère ASCII suivait la forme canonique à barres obliques et ses échappements. Une barre initiale le rendait relatif à la racine du serveur ; sinon, il partait du répertoire associé au descripteur public. L’octet initial 0x80 annonçait la syntaxe native du serveur.

Les liens symboliques formaient une étape autonome. Le serveur suivait ceux des composants intermédiaires, mais renvoyait le descripteur d’un lien placé en dernier. Le client lisait alors son contenu avec READLINK : cible absolue réévaluée depuis le descripteur public, cible relative substituée à l’emplacement du lien. Cette procédure client n’était définie que pour un lien obtenu par recherche canonique multi-composants.

Enfin, un LOOKUP NFS ordinaire ne franchissait généralement pas un point de montage du serveur. Le franchissement depuis le descripteur public supposait à la fois un système de fichiers de destination exporté et la sémantique correspondante du RFC 2055. Un descripteur final atteste ainsi une résolution précise, à un instant et sous une politique donnés ; il ne garantit pas la permanence du nom ni l’innocuité de tous ses détours.

Ne pas fusionner les reçus

Trois faits doivent rester dans trois colonnes : un port a répondu ; le descripteur réservé a été reconnu ; une résolution a produit un descripteur. Pour conclure à un accès réussi, il faut encore établir l’identité attendue, l’authentification et l’intégrité nécessaires, les permissions d’export et d’opération, le comportement des liens, le contenu visé et l’achèvement du READ. La stabilité du stockage et le résultat métier appartiennent à d’autres preuves.

Le RFC 2054 reprend les considérations de sécurité de NFS et de RPC. Il permet de négocier séparément authentification, intégrité et confidentialité. Il ne fait pas du zéro une capacité de sécurité.

Sources