Résumé

  • Le projet draft-ietf-nfsv4-internationalization-17 décrit des comportements NFSv4 légitimes mais différents : comparaison stricte des octets, équivalence Unicode, normalisation ou traitement de la casse. Le client ne peut généralement pas reconstituer toute cette règle à partir d’une réponse positive.
  • Avant une réplication, une restauration ou une migration, il faut produire un reçu d’équivalence de l’espace de noms : séquences exactes, résultats de LOOKUP et READDIR, environnement testé, collisions et limites non observables.

Un résultat, plusieurs explications

Imaginons deux applications qui affichent le même mot accentué. La première a composé le caractère ; la seconde a conservé une lettre et un signe diacritique séparés. À l’écran, la différence est souvent imperceptible. Dans le protocole, ce sont deux suites d’octets. Si le serveur ouvre le fichier pour les deux requêtes, on sait qu’il les a rapprochées. On ne sait pas encore où, comment ni pour combien de temps cette équivalence a été décidée.

Le serveur NFS peut s’appuyer sur le système de fichiers sous-jacent. Une option de montage, une configuration d’exportation, la bibliothèque Unicode ou la logique du serveur peuvent intervenir. Le même logiciel, installé sur deux volumes configurés autrement, peut donc présenter deux politiques de noms. C’est pourquoi le projet de l’IETF demande de considérer séparément les configurations dont le comportement diffère.

Sa révision 17 a été publiée le 11 septembre 2026 après les commentaires de l’IETF Last Call. Le texte est actif, sur la voie Standards Track, et soumis à l’IESG ; ce n’est ni un RFC ni la preuve d’un déploiement. Le rapport d’accompagnement explique aussi une réalité rarement mise au premier plan : le dispositif d’internationalisation prévu pour NFSv4.1 n’a pas été mis en œuvre comme imaginé. Les grandes implémentations citées ont plutôt suivi l’approche de NFSv4.0, qui ne cherche pas à interpréter les noms en UTF-8, tandis que les fonctions conscientes d’Unicode sont restées limitées ou expérimentales.

Ce retour au réel donne au document sa portée. Il ne fabrique pas une pureté rétrospective. Il décrit les choix avec lesquels les opérateurs doivent vivre.

Le régime des octets opaques

Dans un système de fichiers non conscient de l’UTF-8, un composant de nom est une chaîne opaque. Le serveur doit comparer les octets un à un. Ce régime peut accueillir des noms hérités dans d’anciens encodages ou des séquences qui ne sont pas de l’UTF-8 valide. Il conserve une distinction précise : deux suites différentes restent deux noms différents.

Cette fidélité a sa contrepartie. Le serveur ne peut pas promettre que deux formes canoniquement équivalentes d’un caractère Unicode désignent la même entrée, puisqu’il ne reconnaît pas ces caractères. Le nom que l’utilisateur croit retaper à l’identique peut échouer si l’application produit une autre séquence normalisée. Ce n’est pas un aléa d’affichage ; c’est une différence d’identité dans l’espace de noms.

Le régime conscient de l’UTF-8 offre davantage de latitude. Un serveur peut transformer un nom vers une forme de normalisation avant de l’enregistrer. Il peut aussi conserver la graphie reçue tout en acceptant des variantes canoniquement équivalentes lors de la recherche. La casse ajoute une autre dimension : certaines variantes peuvent être fusionnées, mappées ou comparées comme identiques.

La sensibilité linguistique rend la promesse « insensible à la casse » trop courte. Les règles pertinentes peuvent dépendre de la langue ou des préférences de l’utilisateur. Le projet constate qu’aucun mécanisme général de communication de ces choix n’est mûr pour la normalisation. Le mot « Unicode » sur une fiche produit ne fournit donc pas la fonction d’égalité nécessaire à un plan de continuité.

Ce que l’attribut ne dit pas

L’attribut fs_charset_cap apporte un indice étroit : il peut signaler qu’un serveur n’accepte que des noms UTF-8. Le sens historique de FSCHARSET_CAP4_CONTAINS_NON_UTF8 est jugé peu clair ; le projet recommande aux serveurs d’en fournir le complément et aux clients de l’ignorer. Quand l’attribut n’est pas disponible, un essai avec un nom non UTF-8 peut renseigner sur l’acceptation.

Mais accepter exclusivement l’UTF-8 ne dit pas si les noms sont normalisés, sous quelle version d’Unicode, ni quelles variantes de casse sont équivalentes. Un drapeau de capacité répond à « quelles entrées sont recevables ? » bien mieux qu’à « quels noms sont les mêmes ? ».

Une suite de tests réussis ne suffit pas davantage. Elle échantillonne la règle sans la révéler. La dixième variante peut rencontrer un caractère ajouté plus tard à Unicode, une exception de casse ou une politique propre au système de fichiers. Une décision de migration ne devrait pas transformer cet échantillon en garantie générale.

READDIR n’expose pas la relation d’égalité

Lire tout le répertoire paraît fournir une photographie complète. C’est une illusion utile mais dangereuse. Un serveur peut restituer la graphie conservée tout en acceptant une autre graphie équivalente à travers LOOKUP. La liste montre les noms rendus visibles ; elle ne montre pas toutes les requêtes qui atteindraient chaque objet.

Cette asymétrie complique les optimisations du client. Un cache négatif construit avec une notion locale de l’égalité peut mémoriser une absence alors que le serveur aurait accepté une forme équivalente. Un client peut aussi éviter une requête parce que le nom recherché ne semble pas apparaître dans READDIR, puis manquer un objet que le serveur aurait effectivement trouvé. Le projet demande donc au client d’être prêt à la normalisation sans supposer qu’elle aura lieu.

Le temps modifie également le terrain. Les classes d’équivalence canonique peuvent accueillir de nouveaux membres quand Unicode ajoute des caractères. Le document préfère la comparaison indépendante de la forme à l’imposition d’une forme unique, en partie parce que les noms vivent longtemps. Un volume intact peut ainsi changer de contexte sémantique après une mise à niveau.

Copier les données, changer le juge

Une migration ne transporte pas seulement des fichiers. Elle confie leurs noms à un nouveau juge. Si la source distinguait deux suites et que la destination les confond, une collision apparaît. Si la source acceptait deux formes pour la même entrée et que la destination exige les octets exacts, certaines applications perdent leur chemin. Si la destination refuse des noms hérités, une sauvegarde complète sur le plan des contenus devient incomplète sur le plan de l’adressage.

Les vérifications ordinaires détectent mal ces défauts. Le nombre de fichiers peut rester identique avant une collision tardive. Les sommes de contrôle ne disent rien sur la manière de retrouver le contenu. Les tests manuels privilégient les noms connus et les claviers actuels ; ils ignorent précisément les formes rares, historiques ou générées par d’autres bibliothèques.

La réplication peut masquer le problème sous une apparence de convergence. La restauration peut ne le révéler qu’après la perte de la source. Le basculement peut produire une panne où le fichier existe mais où le logiciel ne sait plus formuler son nom.

Un reçu d’équivalence de l’espace de noms

Avant tout changement conséquent, l’équipe devrait établir un reçu d’équivalence. Il ne s’agit pas d’une exigence du projet IETF, mais d’une proposition de gouvernance destinée à rendre la preuve transférable.

Le reçu identifie la version de NFS, le serveur et sa version, le système de fichiers, les options d’exportation et de montage, le système d’exploitation, la bibliothèque Unicode et la date. Il conserve chaque nom testé sous deux formes : une représentation sûre pour l’humain et les octets exacts pour l’audit. L’affichage facilite la revue ; seuls les octets empêchent qu’une normalisation invisible ne réécrive la preuve.

Le jeu d’essai doit partir du corpus réel, puis ajouter des paires ciblées : formes composées et décomposées, variantes de casse pertinentes, octets non UTF-8 déjà présents, caractères susceptibles de changer de traitement selon les versions. Dans une zone contrôlée, on compare LOOKUP, les filehandles renvoyés, la graphie de READDIR, l’acceptation à la création et le comportement après purge des caches négatifs.

Chaque résultat est classé comme observation, déclaration du fournisseur ou hypothèse non testable. Les collisions, refus et ambiguïtés reçoivent un propriétaire et une décision : renommage réversible, échappement, quarantaine, couche de compatibilité ou acceptation documentée. Si un renommage est nécessaire, la table de correspondance doit survivre au système source.

Le reçu doit rester modeste. Le contenu d’un lien symbolique demeure opaque selon d’autres règles ; les noms de domaine non ASCII suivent le cadre des U-labels ; toutes les chaînes NFS ne se traitent pas de la même manière. Il ne certifie pas « Unicode ». Il certifie un ensemble borné de relations observées dans un environnement identifié.

Limite de la preuve

RFC 6943 rappelle qu’une mauvaise comparaison d’identifiants peut provoquer faux positifs, faux négatifs, déni de service et parfois élévation de privilèges. Cela ne constitue pas le récit d’un incident NFS, et le projet n’en revendique aucun. Cela suffit en revanche à placer les règles de noms dans l’analyse de sécurité quand un chemin commande un droit, une politique ou l’exécution d’un programme.

La conclusion tient en une phrase : le succès de LOOKUP prouve qu’un serveur a résolu une suite d’octets, dans sa configuration présente. Il ne prouve ni l’identité universelle des caractères ni la répétabilité de cette décision ailleurs. Avant de déplacer les données, il faut donc déplacer aussi la preuve du sens donné à leurs noms.

Sources