Network File System

NFS im OSI-Schichtenmodell

Anwendung	NFS
Darstellung	XDR
Sitzung	(Sun-) RPC
Transport	UDP		TCP
Netzwerk	IP
Netzzugang	Ethernet	Token Ring	FDDI	...

Der Network File Service - abgekürzt NFS (früher: Network File System) - ist ein von Sun Microsystems entwickeltes Protokoll, das den Zugriff auf Dateien über ein Netzwerk ermöglicht. Dabei werden die Dateien nicht wie z.B. bei FTP übertragen, sondern die Benutzer können auf Dateien, die sich auf einem entfernten Rechner befinden, so zugreifen, als ob sie auf ihrer lokalen Festplatte abgespeichert wären.

Bei diesem UNIX-Netzwerkprotokoll handelt es sich um einen Internet-Standard (RFC 1094, RFC 1813), der auch als verteiltes Dateisystem (engl. Distributed File System) bezeichnet wird.

Die Entsprechung zu NFS heißt unter Windows- und OS/2-Umgebungen Server Message Block (SMB). Während sich bei SMB der Benutzer authentifiziert, authentifiziert NFS V3 den Client-Rechner, erst NFS V4 soll Benutzerauthentifikation erlauben. NFS-Dienste sind auch auf Microsoft-Windows-Servern verfügbar, wodurch UNIX-Workstations Zugang zu deren Dateien erhalten können, allerdings wird in gemischten Umgebungen meist SMB mit Samba auf Unixseite verwendet.

NFS arbeitet auf dem Netzwerk-Transportprotokoll TCP/IP. NFS ist ursprünglich ein zustandsloses UDP-Protokoll. Mittlerweile gibt es aber auch NFS über TCP. Derzeit wird NFS Version 4 entwickelt, welches schneller und nicht mehr zustandslos sein soll.

Design der frühen Versionen des Systems

Ein Programm greift auf das Dateisystem über Systemaufrufe zu. Unter UNIX sind die wichtigsten Systemaufrufe:

• open,close - Öffnen und Schließen einer Datei
• read, write - Lesen und Schreiben
• create, unlink - Erzeugen und Löschen
• mkdir, rmdir - Erzeugen und Löschen eines Verzeichnisses
• readdir - Lesen von Verzeichniseinträgen

Ein Netzwerkdateisystem muss diese Aufrufe in Netzwerkpakete verpacken und an einen Server senden. Dieser antwortet dann mit der entsprechenden Information oder einem Fehler.

Die Entwickler von Sun Microsystems entschieden sich zunächst für ein Remote Procedure Call-Modell. Das XDR setzt die Parameter in ein maschinenunabhängiges Format um, die Zugriffe werden dann über RPC wie ein normaler Unterprogrammaufruf behandelt.

Die Systemaufrufe werden aber nicht direkt in RPC-Aufrufe umgesetzt, da dann eine über open geöffnete Datei auch auf dem Server geöffnet werden müsste. Bei vielen Clients wären die Server dann schnell überlastet, da die Maschinen Mitte der 1980er Jahre noch relativ wenig Speicher hatten. Die Aufgaben des Servers wurden daher so einfach wie möglich gehalten, der Server merkt sich keine Dateiinformationen zwischen zwei RPC-Aufrufen. Er ist also zustandslos.

Statt open wird ein lookup-Aufruf implementiert. Dieser liefert ein Datei-"Handle", das die Inodenummer und die Gerätenummer des Massenspeichers auf dem Server enthält. Über dieses Handle kann eine Datei auf dem Server eindeutig identifiziert werden. Unter Unix steht über diese beiden Nummern die Dateiinformation effizient ohne Suche eindeutig zur Verfügung.

Die weiteren Aufrufe wie read oder write müssen stets ein Offset übergeben, so dass der Server auch hier ohne Kenntnis früherer Operation die gewünsche Information eindeutig liefern kann.

Weitere Eigenschaften des Protokolls sind

• nur kurze Cachezeiten (wenige Sekunden) für Verzeichnisinformationen und Dateiattribute
• kein Datencache
• Verwendung des verbindungslosen User Datagram Protocols UDP
• Lock- und Mount-Operationen über zusätzliche Hilfsprotokolle
• Verwendung von Unix-Dateiattributen (zum Beispiel Benutzer-uid)

Trotz des einfachen Designs läuft NFS in normalen Umgebungen gut:

• lokales Netzwerk mit kurzen Antwortzeiten
• Ausführen von Programmen über das lokale Netzwerk
• Normale Benutzeraktivitäten (Editieren, Programme übersetzen)
• Server mit relativ wenig Arbeitsspeicher

Weniger gut ist das Verhalten bei

• gemeinsamer Nutzung von Dateien
• Verwendung über das Internet (lange Antwortzeiten)
• Verwendung von Firewalls (UDP, kein fester Port wegen Portmapper)

Das Protokoll wurde Ende der 1980er Jahre entwickelt. Auch teure Workstations hatten zu dieser Zeit nur wenige Megabytes Arbeitsspeicher, typisch etwa 4 bis 8 MB. Ein NFS-Server kann auf solchen Maschinen aufgrund des Designs trotzdem effizient betrieben werden.

Wegen des zustandslosen Servers kann dieser ohne Datenverlust heruntergefahren und neu gestartet werden. Programme stürzen nicht ab und Benutzer müssen dann einfach warten, bis der Server wieder verfügbar ist.

Plattenlose Workstations

Workstations können über NFS ganz ohne Plattenlaufwerk betrieben werden. Das Betriebssystem und die Betriebsparameter können über Protokolle wie BOOTP und TFTP geladen werden. Ein spezieller Kernel kann dann über NFS bereits auf das Wurzel-Laufwerk unter Unix zugreifen. Spezielle plattenlose Workstations (diskless workstations) wurden von der Firma Sun in den 1990er Jahren angeboten.

Vorteil ist ein verringerter Wartungsaufwand, gemeinsame Nutzung von Plattenplatz sowie einfachere und preiswerte Client-Workstations (Thin-Clients). Bei vielen Clients wird der Server jedoch stark belastet, außerdem sind die Zugriffszeiten über Netzwerk in den meisten Fällen langsamer.

PC-NFS

Sun und andere Firmen boten in den 1990er Jahren auch NFS-Clientsoftware für PCs unter Windows an, das PC-NFS. Der Server musste weiterhin eine Unix-Workstation sein. Bis Windows für Workgroups war der Netzwerkzugriff unter Windows nicht Teil des Betriebssystems. In Unix-Umgebungen wurde der Einsatz von PCs dadurch wesentlich erleichtert.

PC-NFS musste mit den unterschiedlichen Konzepten des DOS/Windows-Systems kämpfen. Die damaligen Windows-Versionen erlaubten nur Dateinamen mit bis zu acht Zeichen, sowie eine drei Zeichen lange Erweiterung, die durch ein Punkt getrennt wurde (z. B. AUTOEXEC.BAT), während Unix 255 Zeichen lange Pfadnamen erlaubte. Die Dateinamen unterschieden im Gegensatz zu DOS zwischen Groß- und Kleinschreibung. PC-NFS musste also zwischen den Dateinamenkonzepten übersetzen.

Ein Unix-Dateiname file.txt erschien als FILE.TXT unter Windows/DOS, während ein Dateiname Dokumentation.txt etwa in DOKU~123.TXT umgesetzt wurde.

NFS Version 4

Die NFS Version 4 stellt eine Neuimplementierung dar, die neuere Erfordernisse berücksichtigt. Sie ist in RFC 3530 standardisiert.

Die Unix-Lastigkeit der frühen Versionen wird soweit wie möglich verringert. Die UNIX-Benutzer- und Gruppennummern werden durch Zeichenketten, etwa Benutzername@Rechnername, ersetzt. Da manche Dateisysteme keine effiziente Implementierung von eindeutigen Dateihandles ermöglichen, werden flüchtige Handles eingeführt, die nur eine bestimmte Zeit zur Verfügung stehen. Unter Unix kann man Handles sehr einfach aus der Geräte- und Inodenummer konstruieren. Auch Dateisysteme, die nicht zwischen Groß- und Kleinschreibung unterscheiden sowie benutzerdefinierte Dateiattribute werden jetzt unterstützt.

Das Mount- und Lockprotokoll sind jetzt Bestandteil des Protokolls selbst, Hilfsprotokolle werden nicht mehr benötigt. Das Protokoll selbst läuft auf dem festen TCP-Port 2049, UDP wird nicht mehr unterstützt. Zwar liefen auch schon frühere Versionen auf diesem Port, die Hilfsprotokolle wurden vom RPC-Portmapper aber dynamisch zugeteilt. Die Verwendung von Firewalls bei NFS-Verbindungen wird durch diese Maßnahmen stark vereinfacht.

Mehrere Anfragen können gebündelt werden (combined request), sie werden dann vom Server ausgeführt und nur eine Antwort muss zurückgesendet werden. Das Protokoll kann damit effizient auch im Wide-Area-Bereich (WAN) eingesetzt werden, zum Beispiel zwischen verschiedenen Standorten einer Organisation.

Verschlüsselung ist jetzt Teil der Spezifikation. Zwar war früher schon über Secure-RPC eine Verschlüsselung möglich. Dies wurde nur selten genutzt, unter anderem, weil Secure-RPC nicht grundsätzlich zur Verfügung stand.

Der lookup-Aufruf wird durch open ersetzt, die Speicherung von Dateiinformationen wird dadurch möglich. Beispielsweise könnte die Schreib-/Leseposition auf dem Server verwaltet werden. Auch die gemeinsame Nutzung von Dateien wird besser unterstützt. Falls viele Clients eine Datei nur lesen, kann diese an alle Clients verliehen (leases) werden. Wenn ein Client eine Datei schreiben möchte, kann diese exklusiv verliehen werden.

Konfiguration in Unix-Systemen

Die NFS-Freigaben werden unter Unix serverseitig meist in der Datei /etc/exports festgelegt. Der Client kann eine Freigabe manuell mounten oder ggf. mit einem Eintrag in der /etc/fstab automatisieren.

Vielen aktuellen Linux-Distributionen liegen grafische Hilfswerkzeuge bei, um die Einbindung von NFS-Freigaben ins System zu vereinfachen.

Sicherheit

NFS wurde geschaffen um in Unix-System-Netzen Dateisysteme über Rechnergrenzen hinweg zugänglich zu machen. Zur Zeit der Entwicklung von NFS waren solche Netze fast ausschließlich zentral verwaltet und die Rechner wurden zentral administriert, entsprechend wurde das Sicherheitskonzept gestaltet.

Ein NFS-Server exportiert Dateisysteme an bestimmte andere Rechner (von root durch IP-Adressen festgelegt), d.h. der root eines Clientrechners kann auf alle Dateien zugreifen, die der Server an den Client exportiert unabhängig von deren Zugriffsrechten. Die Zugriffsrechte (der Benutzer) werden von NFS an den Client mitübertragen und vom Betriebssystem des jeweiligen Rechners ausgewertet und gegenüber den Benutzern durchgesetzt. Die Konsistenz der Benutzerdatenbank auf den beteiligten Rechnern wird dabei z.B. durch NIS erreicht.

Heutzutage sind Rechnernetze oftmals offen und nur bedingt zentral administriert, d.h. ein Angreifer kann relativ einfach entweder einen Rechner, dem der NFS-Server vertraut, übernehmen, indem er ihn z.B. mit Knoppix neu bootet oder einen zusätzlichen Laptop in das Netz hängen und die IP eines gerade nicht laufenden NFS-Clients annehmen. In beiden Fällen kann der Angreifer, da er auf seinem System Rootrechte hat, auf alle an den Client exportierte Dateien, unabhängig von den Zugriffsrechten der Dateien, zugreifen. Somit ist NFS v3 immer nur so sicher, wie das Netz und die beteiligten Rechner.

NFS v4 löst dieses Problem indem z.B. mittels Kerberos eine Benutzeridentifizierung erfolgen kann.

Spezifikationen

• RFC 1094 (NFS Version 2 Protocol Specification)
• RFC 1813 (NFS Version 3 Protocol Specification)
• RFC 3530 (NFS Version 4 Protocol Specification)

Weblinks

• Projektseite (englisch)
• Linux-Implementierung von nfs (englisch)
• Linkkatalog zum Thema NFS bei curlie.org (ehemals DMOZ) (englisch)