Zusammenfassung

  • RFC 2054 empfahl TCP auf Port 2049, danach UDP 2049, NFSv3 mit öffentlichem Handle der Länge null und erst bei bestimmten Fehlern den Rückweg über v2, PORTMAP und MOUNT.
  • Der öffentliche Filehandle war eine reservierte Startreferenz. Er bewies weder Identität noch Exportberechtigung, vollständige Pfadsicherheit oder einen erfolgreichen READ.
  • Multi-Component LOOKUP sparte Nachrichten, ließ aber kanonische und native Pfade, symbolische Links und Dateisystemgrenzen als eigenständige Bedingungen bestehen.

Vor dem ersten Handle standen zwei Dienste

ONC RPC ordnete Programmen Nummern und dynamische Ports zu. Der Binding-Dienst war unter Port 111 erreichbar. Weil MOUNT keinen festen Port besaß, fragte der Client PORTMAP, rief anschließend MOUNTPROC_MNT auf und ließ einen exportierten Pfad in einen vom Server erzeugten Anfangs-Filehandle übersetzen. Erst danach begann NFS.

Die Aufgabentrennung war sinnvoll, verursachte über langsame Verbindungen aber zusätzliche Umläufe. Ein dynamischer MOUNT-Port erschwerte zudem Filter- und Proxy-Passagen. RFC 2054 nutzte die verbreitete Gewohnheit, NFS auf 2049 zu registrieren, als überprüfbare Vermutung: TCP 2049 versuchen, bei Ablehnung UDP 2049 verwenden und PORTMAP nur befragen, wenn beide Wege ohne Antwort bleiben.

Die Antwort eines Ports ist damit ein enges Signal. Sie sagt nichts Verlässliches über NFS-Version, WebNFS-Semantik, Gegenstellenidentität, Exportrecht oder spätere Datenübertragung.

Der Fehler bestimmte die richtige Rücksprungstelle

Nach dem Kontakt nahm der Client WebNFS und NFSv3 an und sandte üblicherweise LOOKUP mit dem öffentlichen v3-Handle. PROG_MISMATCH widerlegte die Programmversion; folglich wurde mit NFSv2 und dessen öffentlichem Handle wiederholt.

NFS3ERR_STALE, NFS3ERR_INVAL oder NFS3ERR_BADHANDLE widerlegten dagegen die Public-Handle-Annahme. Der Client musste MOUNT über PORTMAP finden und einen gewöhnlichen Anfangs-Handle beziehen. Verweigerte TCP-Verbindung, ausbleibende UDP-Antwort, Versionskonflikt und Handle-Ablehnung sind verschiedene Belege, weil sie verschiedene Reparaturen verlangen.

Null war ein Treffpunkt, kein Ausweis

Gewöhnliche Filehandles waren opake Serverwerte. Die öffentliche Ausnahme bestand in NFSv2 aus 32 Null-Oktetten und in NFSv3 aus einem Handle der Länge null. Sie kodierte weder inode noch Benutzer, Exportname, Geheimnis oder Recht. Sie bat den Server, an einer administrativ zugeordneten Stelle mit besonderer Semantik zu beginnen.

RFC 2055 begrenzte das Wort „öffentlich“. Für ein Ziel außerhalb exportierter Dateisysteme musste der Server einen Fehler liefern. Auch ein Pfad in ein zweites exportiertes Dateisystem war nicht automatisch zugelassen. Verließ sich eine Implementierung auf die MOUNT-Zugriffsprüfung, konnte sie den übersprungenen MOUNT-Schritt nicht als Freigabe ersetzen. Nur ein Server, der Exportzugriff bei jeder NFS-Anfrage prüfte, hatte mehr Spielraum.

Ein LOOKUP bündelte Pfadarbeit, nicht Autorität

Normales LOOKUP löste einen Namensbestandteil relativ zu einem Verzeichnis-Handle auf. WebNFS erlaubte nur relativ zum öffentlichen Handle eine Anfrage für a/b/c und konnte den letzten Handle in einem Umlauf zurückgeben.

Ein ASCII-Anfang wählte den kanonischen, slash-getrennten Pfad mit festgelegten Escapes. Ein führender Slash begann an der Serverwurzel, andernfalls am Verzeichnis des öffentlichen Handles. Das Startoktett 0x80 leitete die native Serversyntax ein. Beide Formen waren eigenständige Auslegungsregeln.

Zwischenliegende symbolische Links wertete der Server aus. War der letzte Bestandteil selbst ein Link, gab er dessen Handle zurück; der Client las ihn mit READLINK. Absolute Ziele gingen erneut vom öffentlichen Handle aus, relative ersetzten den letzten Pfadteil an der Linkposition. Dieses Clientverfahren definierte RFC 2054 nur für Links aus kanonischem Multi-Component LOOKUP.

Gewöhnliches NFS-LOOKUP überschritt außerdem üblicherweise keinen Server-Mountpoint. Die öffentliche Variante durfte dies nur, wenn das Ziel exportiert war und RFC 2055-Spanning unterstützt wurde. Ein Ergebnis bewies somit eine einzelne Auflösung unter damaligem Namespace und damaliger Policy, nicht die dauerhafte Integrität des ganzen Pfades.

Drei Quittungen bleiben drei Aussagen

Portantwort, Anerkennung des Null-Handles und LOOKUP-Erfolg bilden keine gemeinsame Vollmacht. Für erfolgreichen Dateizugriff fehlen noch die erwartete Gegenstelle, nötige Authentisierung und Integrität, Export- und Operationsrechte, Link- und Übergangsverhalten, erwarteter Inhalt sowie der abgeschlossene READ. Dauerhaftigkeit und Geschäftsergebnis verlangen weitere Beobachtungen.

RFC 2054 übernahm die Sicherheitsbetrachtungen von NFS und RPC und ließ sichere Verbindungen gesondert aushandeln. Die leere Referenz wurde dadurch nicht zum Sicherheitstoken.

Quellen