Mit NFSv4 bekommen Administratoren ein weiteres sicheres Netzwerkdateisystem für Linux, das mit diversen Unix-Systemen kompatibel ist. Unter anderem setzen Sun Solaris 10, »FreeBSD 5.2« oder IBM AIX 5.3 auf die Alternative zum Andrew-Filesystem (AFS). Wichtigste Neuerung ist die Unterstützung der Generic-Security-Services API (GSS-API), mit deren Hilfe sich sowohl die Kommunikation der Remote-Procedure-Calls (RPC) sichern lässt als auch die Nutzdaten verschlüsselt werden. Letzteres ist allerdings auf Linux noch nicht implementiert.

Bereits funktionsfähig in der derzeit erhältlichen Beta-Version des NFSv4-Server und -Client ist die Sicherung des RPC-Traffic über das Ticket-System Kerberos 5. Dazu unterstützt NFSv4 den Mechanismus RPCSEC_GSS. Damit lässt sich die Authentifikation über verschlüsselte Tickets sichern oder der gesamte RPC-Verkehr codieren.

Als angenehme Neuerung reduziert das Pseudodateisystem den Verwaltungsaufwand. Damit lassen sich mehrere Dateisysteme zusammenfassen und als einziges Filesystem exportieren. Der Client benötigt somit nur noch einen Mount-Punkt, unter dem sich alle Exporte versammeln.

Der Firewall-Regelsatz ist zudem einfach zu erweitern. NFSv4 verlangt lediglich, dass Port »2049/tcp« geöffnet ist. Distributionen mit einer Kernel-Version 2.6.5 oder höher enthalten bereits die NFSv4-Treiber für Server und Client. Um das Dateisystem einzuhängen, benötigt der Anwender zudem ein »mount«-Kommando, das »nfs4« als Dateisystemtyp erkennt. Diese Voraussetzungen erfüllen bisher lediglich Gentoo, Redhat-Fedora-Core 4 und Suse-Linux 10.0. Wer eine andere Distribution einsetzt oder Debugging-Informationen erhalten möchte, stattet die Kernelquellen mit den Patches des bei der NFSv4-Entwicklung federführenden Center-for-Information-Technology-Integration (Citi) der Universität von Michigan aus. Die Seite ist auf http://www.citi.umich.edu/projects/nfsv4/ erreichbar.

Ungepachtes System vorbereiten

Zuerst benötigen Sie einen Kernel mit NFSv4-Unterstützung. Das Citi empfiehlt die Quellen der Version 2.6.14, die bereits entsprechend ausgestattet sind. Die Quellen entpacken Sie unter »/usr/src« und backen einen neuen Kernel. Die NFSv4-Unterstützung für Client und Server befindet sich in der Rubrik »File systems« im Menü »Network filesystems«. Außerdem benötigen Sie die Option »Provide server over TCP support«. Die notwendigen Verschlüsselungsmodule »MD5 digest algorithm« sowie »DES and triple DES EDE cipher algorithms« in »Cryptographic Options« im Menü »Cryptographic API« sind standardmäßig aktiv. Access-Control-Lists aktivieren Sie für jedes Dateisystem, das Sie einsetzen, unter »File systems«. Wählen Sie die Module »Extended Attributes« sowie »POSIX Access Control Lists«. In diesem Workshop verwendeten wir lediglich Ext3.

Der Workshop benutzt die Datei »/etc/hosts«, um die IP-Adressen den Hostnamen zuzuordnen. An der IP-Adresse 192.168.10.151 befindet sich der NFS-Server »server.example.net«. Die Workstation »client.example.net« ist über 192.168.10.99 erreichbar.

Für den Test sollten die Firewalls auf Client und Server der Einfachheit halber deaktiviert sein. Sobald der Server steht, öffnen Sie den Port 2049. Dies ist der einzige nötige Port, wenn NFSv4 mit der klassischen Anmeldemethode »AUTH_SYS« arbeitet. Auf Novell/Suse steht zur Bearbeitung der Firewall-Regeln ein Yast2-Modul zur Verfügung. Auf Redhat lässt sich die Firewall mit dem grafischen Werkzeug »system-config-securitylevel« oder der Textalternative »system-config-securitylevel-tui« einstellen. Fügen Sie einfach den Eintrag »2049:tcp« unter der Option »andere Ports« hinzu. Das Programm trägt eine passende Zeile in das Regelwerk »/etc/sysconfig/iptables« ein und aktualisiert den laufenden Paketfilter.

Basisdienste einstellen

Die Sicherung des Portmappers steht an erster Stelle. Dieser beantwortet die Anfrage der Clients nach der Portnummer des NFS-Dienstes. Damit nicht ein x-beliebiger Client den NFS-Server kontaktieren kann, lässt sich mit dem TCP-Wrapper einstellen, von welchen IP-Adressen der Zugriff zulässig ist. Für NFSv4 reicht es, in der Datei »/etc/hosts.allow« lediglich Verbindungen aus dem Loopback (127.0.0.0) zuzulassen:
portmap: 127. : ALLOW
portmap: ALL : DENY
Zugriffe von allen anderen Adressen (ALL) wehrt der TCP-Wrapper ab (DENY).

Prüfen Sie dann, ob die Startdatei des NFS-Servers »/etc/sysconfig/nfs« existiert. Folgende Einträge sollten vorhanden sein:
SECURE_NFS="no"

RPCNFSDCOUNT=8

Die erste Zeile deaktiviert die Option, Kerberos 5 für eine sichere Authentifizierung im lokalen Netzwerk zu verwenden. Diese an sich wichtige Funktion stört an dieser Stelle der Konfiguration nur, lässt sich aber nachholen, sobald der Server zufrieden stellend läuft (siehe Kasten »Mehr Sicherheit dank Kerberos 5"«). Der zweite Eintrag lässt maximal acht Verbindungen zum NFS-Server zu.

Obwohl Sie die Sicherheitsfunktion mit der GSS-API nicht nutzen, muss die dazu gehörige Konfigurationsdatei »/etc/gssapi_mech.conf« existieren. Darin sollte der Eintrag »/usr/lib/libgssapi_krb5.so« auf »mechglue_internal_krb5_init« verweisen.

Der ID-Mapper-Daemon sorgt für die Umwandlung von NFSv4-Benutzern »user@domain« in User- und Gruppen-IDs (frühere NFS-Versionen). Dies ist hier nur nötig, da der Sicherheitsmechanismus »AUTH-SYS« die User- und Group-ID zur Authentifikation nutzt. Verwaltet der Kerberos-Dienst die Accounts, benötigt der Administrator den Daemon nicht.

Der Mapper-Dienst »idmapd« ist schnell konfiguriert. Sie passen in der Konfigurationsdatei »/etc/idmapd.conf« lediglich die Domain an und setzten den anonymen NFS-Benutzer ein (siehe »ID-Mapper-Daemon konfigurieren«).

ID-Mapper-Daemon konfigurieren

#/etc/idmapd.conf

[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs

Domain = example.net

[Mapping]
Nobody-User = nfsnobody

Nobody-Group = nfsnobody

Beachten Sie, dass Server und Client auf jeden Fall dieselbe Domain im Abschnitt »[General]« benutzen. Die Option »Verbosity=0« deaktiviert Fortschrittsmeldungen des Daemons. Unter der Rubrik »[Mapping]« tragen Sie den anonymen NFS-Benutzer ein, in dessen Kontext die Anwender arbeiten. Auf Redhat heißt dieser »nfsnobody«, Novell/Suse nennen ihn einfach »nobody«. User-ID und Group-ID sind in beiden Distributionen »65534«.

Export-Verzeichnis anlegen

Nun ist der Server so weit eingestellt, dass Sie die gemeinsam genutzten Verzeichnisse anlegen können. Der Workshop benutzt »/home/NFSv4« als Tauschverzeichnis.

mkdir -m 1777 /home/NFSv4

Mit dem Wert »1777« darf jeder Benutzer alles (lesen, schreiben, ausführen). Die »1« steht für das Sticky-Bit. Dies erlaubt einem entfernten Benutzer, im Verzeichnis zu lesen und zu schreiben, jedoch nur der Eigentümer der darin liegenden Dateien darf diese löschen oder ändern.

Dass Access-Control-Lists (ACLs) für die NFS-Shares gelten sollen, stellt der Verwalter in der Datei »/etc/fstab« ein. Dort reicht es, die »acl« im Optionsfeld einzutragen:

LABEL=/home /home ext3 rw,acl

Nach dem Eingriff mountet der Benutzer »root« die Partition neu. Dies gelingt mit einem Neustart oder schneller mit der Option »remount«: mount -v -o remount /home

Nun lassen sich bereits Dateien in »/home/ NFSv4« kopieren, mit denen Sie später den Lese- und Schreibzugriff testen.

Dienste starten und stoppen

Alle für NFSv4 notwendigen Dienste bringen Sie jetzt dazu, beim Booten in den richtigen Runlevels zu starten. Hierzu dienen Skripte, die sich im Verzeichnis »/etc/init.d« aufhalten. Auf Novell/Suse lassen sich die Runlevel in Yast2 mit dem »Runlevel-Editor« aus der Rubrik »System« einstellen. Redhat liefert dazu das Werkzeug »system-config-services«. Auf der Kommandozeile lassen sich die Dienste mit »chkconfig« auf beiden Systemen konfigurieren. Damit stellt der Administrator ein, dass die Dienste in bestimmten Runlevels automatisch starten und anhalten.
chkconfig --level 0123456 portmap off

chkconfig --level 345 portmap on

Dies führen Sie der Reihe nach für die Dienste »portmap«, »rpcidmapd«, »nfslock« und die Dienstsammlung »nfs« durch. Die erste Zeile deaktiviert den jeweiligen Dienst in allen Runlevels. Anschließend aktivieren Sie die Services für die Runlevel 3 (Netzwerk ohne X11), 4 (nicht benutzt) und 5 (Netzwerk mit X11).

Die Dienste »rpcgssd« und »rpcsvcgssd« schalten Sie zudem in allen Runlevels aus. Diese sind für die erweiterte Sicherheit mit GSS-API nötig, mit der sich verschlüsselte Verbindungen zum Portmapper aufbauen lassen. Dies konfigurieren wir im Workshop jedoch nicht.

Jetzt prüfen Sie, ob die Dienste wie vorgesehen starten und anhalten. Zuerst stoppen Sie »rpcgssd« und »rpcsvcgssd«:
/etc/init.d/rpcgssd stop

/etc/init.d/rpcsvcgssd stop

Anschließend lässt sich mit dem Parameter »restart« die ordnungsgemäße Funktion der Dienste testen. Auch hier ist wieder auf die Reihenfolge zu achten:
/etc/init.d/portmap restart
/etc/init.d/rpcidmapd restart
/etc/init.d/nfslock restart

/etc/init.d/nfs restart

Der Befehl rpcinfo -p fördert nun alle für NFSv4 benötigten Dienste zu Tage. Das Kommando gibt zudem das dazu passende Protokoll sowie den Port aus, an dem der jeweilige Dienst auf Client-Anfragen lauscht.

Accounts anlegen

Zum vorläufigen Abschluss der Server-Konfiguration legen Sie zwei Testbenutzer an. Um einen Account anzulegen, verwenden Sie das Kommando »useradd«:
useradd -d /home/anton -u 1000 anton
useradd -d /home/berta -u 1001 berta

Notieren Sie sich die Benutzernamen sowie die dazu gehörigen User- und Gruppen-IDs (1000, 1001). Diese müssen identisch mit den Accounts der NFSv4-Clients sein.

Server exportiert

Zuerst mounten Sie das »NFSv4«-Verzeichnis im Nur-Lese-Modus. Tragen Sie das Verzeichnis dazu auf dem Server in die Datei »/etc/exports« ein. Darin führen Sie jedes Share auf und geben einzelnen Exportverzeichnissen bestimmte Optionen mit. Für »NFSv4« benutzen Sie folgende Zeile:
/home/NFSv4 192.168.10.0/24(ro,fsid=0,insecure,
no_subtree_check,sync,anonuid=65534, anongid=65534)

Die Angabe »fsid=0« weist den NFS-Server zudem an, das neu integrierte Pseudodateisystem zu verwenden. Um Schreibzugriff zuzulassen, ersetzen Sie die Option »ro« einfach durch »rw«.

Nun starten Sie den NFS-Server mit der geänderten Konfiguration neu. Dazu dient das Kommando »exportfs« mit der Option »r«, das der Verwalter nach jeder Änderung der »exports«-Datei ausführen muss.

exportfs -r

Das Kommando showmount -e gibt eine Liste aller Exporte aus. So lässt sich im laufenden Betrieb ein schneller Überblick gewinnen.

NFSv4-Client konfigurieren

Das Einrichten des NFSv4-Clients läuft im Wesentlichen so ab wie die Konfiguration des Server-Diensts. Zwingend nötig ist ein »mount«-Befehl aus dem Paket »util-linux«, der mit NFSv4 umgehen kann. Einen passenden Patch stellt das Citi auf der Website bereit.

Tragen Sie zuerst Server und Client in die »/etc/hosts« ein. Eine eventuell auf dem Client wachende Firewall darf aktiv bleiben. Änderungen sind nicht vorzunehmen. Konfigurieren Sie den Portmapper wie beim Server. Prüfen Sie, ob die Datei »/etc/gssapi_mech.conf« existiert und die gleichen Einträge wie auf dem Server enthält. Auch der ID-Map-Daemon auf dem Client muss in »/etc/idmapd.conf« identisch konfiguriert sein.

Passen alle Konfigurationsdateien, legen Sie die Mount-Punkte an. Dabei handelt es sich um Verzeichnisse, unter denen der Client die entfernten Dateisysteme einhängt. Darauf greift der Benutzer dann normal mit einem Dateimanager zu; so, als befänden sich die Daten auf dem lokalen System.

Der Inhalt unter »/home/NFSv4« soll auf dem Client unter »/mnt/NFSv4« auftauchen. Die Benutzer dürfen im Share nur lesen (ro) oder auch schreiben und löschen (rw).

mkdir -m 755 /mnt/NFSv4

Der Wert »755« setzt die Rechte passend: Der Eigentümer darf alles, die Gruppe des Eigentümers sowie der Rest der Benutzer dürfen nicht in das Verzeichnis schreiben.

Start und Stop der Dienste

Auch auf dem Client müssen die NFS-Dienste automatisch nach dem Booten aktiv sein. Dazu ist es wieder nötig, die Init-Skripte in bestimmten Runlevels starten zu lassen. Wie auf dem Server starten die Skripte in 3, 4 und 5. Nötig sind ausschließlich die Services »portmap« und »rpcidmapd«.

Die NFS-Dienste »nfslock« und »nfs« deaktivieren Sie in jedem Runlevel genauso wie die Sicherheitsdaemonen »rpcgssd« sowie »rpcsvcgssd«. Anschließend starten Sie die Daemonen »portmap« und »rpcidmapd« per Init-Skript und den Parameter »restart«:
/etc/init.d/portmap restart

/etc/init.d/rpcidmapd restart

Mit »rpcinfo -p« lässt sich wieder prüfen, ob der Portmapper korrekt hochgefahren ist und an Port 111 lauscht.

Benutzer synchronisieren

Nun kommen die Accounts der Benutzer an die Reihe. Fügen Sie »anton« und »berta« zusammen mit der passenden User- und Gruppen-ID dem Client-System hinzu:
useradd -u 1000 anton

useradd -u 1001 berta

Sobald Sie die einzelnen Benutzer mit einem Passwort versorgt haben, lassen sich die freigegebenen Verzeichnisse zum ersten Mal vom Client mounten.

Client importiert

Zuerst mounten Sie das NFS-Dateisystem »/home/NFSv4« manuell per Kommandozeile in das lokale Verzeichnis »/mnt/NFSv4« auf dem Client:
mount -t nfs4 -o ro,intr server:/ /mnt/NFSv4
Den kompletten Pfad zum Share braucht der Administrator bei NFSv4 nicht anzugeben. Es reicht der Eintrag »server:/«. Danach können die Benutzer »anton« und »berta« im Verzeichnis lesen und Dateien kopieren. Einen Schreibzugriff quittiert der Server mit einer Fehlermeldung, da das Dateisystem »read-only« gemountet ist. Sind die Test erfolgreich verlaufen, lösen Sie den Export wieder auf:

umount /mnt/NFSv4

Nun lassen sich die Optionen in die Datei »/etc/fstab« dauerhaft eintragen, so dass sich das entfernte »NFSv4«-Verzeichnis mit einem kurzen Befehl einhängen lässt. Fügen Sie dazu folgende Zeile in die »fstab«-Datei des Clients ein:
server:/ /mnt/NFSv4 nfs4 ro,hard,intr,proto=tcp,

port=2049,noauto 0 0

Anschließend lässt sich das entfernte Dateisystem mit einem einfachen »mount«-Kommando einhängen.

mount -v /mnt/NFSv4

Mit dem Befehl »netstat« können Sie sehen, dass danach eine Verbindung zum Server an Port 2049 besteht: netstat -tn

Wenn der Read-only-Test erfolgreich war, gewähren Sie ihren Benutzern nun Schreibzugriff auf das NFS-Verzeichnis. Dazu entfernen Sie das »NFSv4«-Verzeichnis zuerst aus dem Verzeichnisbaum mit dem Kommando »umount«.

Schreibzugriff einstellen

Damit die Benutzer in das Verzeichnis schreiben können, tauschen Sie die Option »ro« einfach mit »rw« (read write). Das Sticky-Bit, das Sie vorher beim Erstellen des Verzeichnisses »NFSv4« gesetzt haben, verhindert, dass ein Benutzer eine Datei löscht oder ändert, deren Eigentümer er nicht ist.

Auch der Benutzer »root« hat auf dem Server nur eingeschränkte Rechte. Dafür sorgt die Option »root_squash«, die standardmäßig aktiv ist. Root arbeitet dadurch im Kontext des Benutzers »nfsnobody«, wie Sie es in der Konfigurationsdatei des ID-Mapper angegeben haben.

Auf dem Server ersetzen Sie in »/etc/exports« ebenfalls »ro« mit dem Kürzel »rw«. Anschließend exportieren Sie das Verzeichnis erneut:

exportfs -rv

Das Gleiche machen Sie auf dem Client. Ersetzen Sie das »ro« in »/etc/fstab« durch »rw« und mounten das Dateisystem neu:

mount -v /mnt/NFSv4

Nun sollten Sie ein paar Tests durchführen. Schreiben Sie als Benutzer »anton« oder »berta« in Dateien, legen Sie welche an oder löschen Sie diese. Wenn diese Benutzer eine Datei oder ein Verzeichnis anlegen, erhalten sie die Rechte des Benutzers. Lediglich Root verliert den Status, weshalb die Dateien als Eigentümer den Benutzer »nfsnobody« ausweisen.

NFSv4 ist nun so weit konfiguriert, dass die Benutzer per »mount«-Befehl das entfernte Dateisystem einhängen können. Soll dies automatisch beim Systemstart geschehen, ersetzen Sie die Option »noauto« in der »/etc/fstab« durch »auto«. Somit hängt »mount« alle in »fstab« aufgeführten NFSv4-Dateisysteme automatisch ein.

Pseudodateisystem nutzen

Im Abschnitt zu den »exports«-Optionen haben wir empfohlen, die Option »fsid=0« zu setzen. Damit ist das neue NFSv4-Pseudodateisystem aktiv. Es erlaubt dem Administrator, unter einem einzigen Export-Verzeichnis alle freigegebenen Verzeichnisse logisch zusammenzuführen – egal, wo diese tatsächlich liegen. Der Client muss dann lediglich dieses eine Verzeichnis mounten statt wie früher jedes einzelne Dateisystem.

Um diese lange erwartete Funktion zu testen, legen Sie zwei weitere Verzeichnisse an. Wir benutzen das Verzeichnis »/pseudo1« auf der Partition »/dev/sda6« und »/pseudo2« im Root-Directory von »/dev/sda1«.

Bevor Sie die Verzeichnisse zusammenführen, muss der Client die importierten Dateisysteme unmounten. Anschließend wechseln Sie auf den Server und halten diesen an:

/etc/init.d/nfs stop

Nun legen Sie die Verzeichnisse »pseudo1« und »pseudo2« an. Beide sollten wieder mit den Rechten »1777« ausgestattet sein. Nun kopieren Sie einige Dateien aus »/etc« oder »/var« in die beiden Verzeichnisse, um später damit zu experimentieren.

Legen Sie jetzt die Mount-Punkte für »pseudo1« und »pseudo2« auf dem Server an. Dies erledigen Sie am besten auch unter »/home/NFSv4«:
mkdir /home/NFSv4/pseudo1

mkdir /home/NFSv4/pseudo2

Nun hängen Sie die beiden ein:
mount --bind /pseudo1 /home/NFSv4/pseudo1
mount --bind /pseudo2 /home/NFSv4/pseudo2

Die Option »--bind« ist für diese Operation zwingend. Sie bindet die beiden Verzeichnisse an das Container-Verzeichnis »NFSv4.

Jetzt sind die Optionen in »/etc/exports« an der Reihe. Hier fügen Sie die beiden Verzeichnisse mit der Option »nohide« dazu. Den alten Eintrag für »/home/NFSv4« lassen Sie unangetastet.
/home/NFSv4/pseudo1 192.168.10.0/24(rw,nohide,insecure,no_subtree_check,sync,anonuid=65534, anongid=65534)
/home/NFSv4/pseudo2 192.168.10.0/24(rw,nohide,insecure,no_subtree_check,sync,anonuid=65534, anongid=65534)

Starten Sie den Server mit /etc/init.d/nfs start
und lassen Sie sich mit »exportfs -rv« die Exporte anzeigen.

Die »/etc/fstab« auf dem Client müssen Sie mit NFSv4 nicht anpassen. Der vorher angelegte Eintrag »server:/« reicht, um den gesamten exportierten Verzeichnisbaum zu sehen. Frühere NFS-Versionen erwarten hier den kompletten Pfad. Nach der Änderung auf dem Server lassen sich alle freigegebenen Dateisysteme mit einem einzigen Befehl mounten:

mount -v /mnt/NFSv4

Wechseln Sie nun in das Verzeichnis »/mnt/NFSv4« und schauen Sie sich um. Die Verzeichnisse »pseudo1« und »pseudo2« sind ebenso da wie die Dateien aus dem NFSv4-Verzeichnis. Die Option »--bind« lässt sich nicht in die »/etc/fstab« eintragen. Somit ist die schöne Konfiguration nach einem Neustart des Servers verloren. Um die Verzeichnisse bei jedem Start automatisch unter »/home/NFSv4« einzuhängen, tragen Sie die Befehlszeile in die Datei »/etc/rc.local« ein.

NFS über Internet fehlt noch

Eine entscheidende Funktion fehlt dem Linux-NFSv4 noch: Die sichere Kommunikation über das Internet. Diese hängt vom SSL-ähnlichen »LIPKEY«-Mechanismus (Low Infrastructure Public Key) ab, der allerdings noch nicht implementiert ist. Das Protokoll ist eigens für RPC-Anwendungen gedacht und benutzt UDP als Transportprotokoll.

Das Netzwerkdateisystem zu sichern, wenn es über ein öffentliches Netzwerk gemountet wird, dürfte entscheidend für den weiteren Erfolg von NFSv4 sein. Mit Samba kündigt quasi die Konkurrenz im eigenen Lager ebenfalls enorme Sicherheitsverbesserungen für Version 4 an, die für Ende 2005 erwartet wird.

jr@networkcomputing.de