/etc/exports – NFS Dateisysteme, die freigegeben werden sollen (für kernelbasiertes NFS)

Syntax

/etc/exports

Beschreibung

Die Datei /etc/exports dient als Zugriffskontrolle für Dateisysteme, die über NFS exportiert (freigegeben) werden sollen. Sie wird von exportfs benutzt, um Informationen an mountd und den kernelbasierten NFS-Daemon nfsd weiterzugeben.

Das Dateiformat ähnelt dem orginal SunOS Dateiformat. Jede Zeile enthält einen Verzeichnisnamen und eine durch Leerzeichen getrennte Liste von Clients, die dieses Verzeichnis mounten dürfen. Jeder Angabe eines Clients darf in Klammern eine Liste von durch Kommata getrennten Exportoptionen für diesen Client folgen. Zwischen der Angabe des Clients und seiner Optionsliste darf kein Leerzeichen stehen.

  Verzeichnisname     Client(Optionen) Client2(Optionen2) 

Maschinen-Namensformate

Clients werden meist als Hostnamen angegeben, es gibt aber auch andere Angabemöglichkeiten:

Ein einfacher Rechnername

Hier kann entweder ein einfacher Hostname, ein voller Hostname mit Domainnamen oder eine IP-Adresse stehen.

Netzgruppen

NIS-Netzgruppen werden als @Gruppenname angegeben. Nur der Rechnerspezifische Teil der Netzgruppe wird verwendet. Leere rechnerspezifische Teile oder solche, die nur einen Bindestrich enthalten werden ignoriert.

Jokerzeichen/Muster

Rechnernamen dürfen die Suchmuster * und ? beinhalten. Diese Muster sind in einem Domainnamen aber nur innerhalb der einzelnen Teile gültig. Mit *.cs.foo.edu werden zwar alle Rechner der Domain cs.foo.edu gemeint, die keine weitere Subdomainunterteilung benutzen, der Rechner a.b.cs.foo.edu ist aber nicht gemeint. Jokerzeichen passen also nicht auf die Punkte, die Domainnamen trennen.

IP-Netzwerk-Adressen

Auch Netzwerkadressen in der Form Adresse/Netzmaske können benutzt werden, um allen Rechnern, auf die diese Adresse passt den Zugriff zu erlauben. Die Netzmaske kann entweder in der traditionellen Weise mit z.B. /255.255.252.0 angegeben werden oder wie heute immer üblicher einfach als Anzahl der gesetzten Bits, hier also /22

Generelle Optionen

exportfs versteht die folgenden Export-Optionen:

secure

Diese Option verlangt, daß Nachfragen von einem privilegierten Internet-Port unter 1024 stammen. Diese Option ist standardmäßig aktiviert. Um sie auszuschalten muß insecure benutzt werden.

rw

Erlaubt beides, Lesen und Schreiben, auf diesem NFS-Laufwerk. Der voreingestellte Modus ist es, alle Nachfragen zu verbieten, die Änderungen am Dateisystem vornehmen wollen. Das kann auch explizit mit ro eingestellt werden.

sync

Diese Option erwartet es, daß alle Schreibzugriffe, die an das freigegebene Laufwerk weitergegeben werden, tatsächlich geschrieben werden, bevor der Befehl als ausgeführt quittiert wird. Das wird für erhöhte Sicherheit der Daten bei einem Servercrash verlangt, bringt aber einen Performance-Einbruch. Voreingestellt ist es, dem Server zu erlauben, die Daten im Cache zwischenzuspeichern und erst tatsächlich auf die Platte zu schreiben, wenn er das nächste Mal Gelegenheit dazu hat. Das kann auch explizit mit async eingestellt werden.

no_wdelay

Diese Option hat nur im Zusammenhang mit sync einen Effekt. Ein NFS-Server würde normalerweise einen Schreibzugriff auf die Platte etwas verschieben, wenn er davon ausgeht, daß ein anderer, verwandter Schreibzugriff gerade oder bald ankommt. Das ermöglicht es, mehrere Schreibzugriffe in einem Aufwasch zu erledigen was die Performance steigern kann. Wenn ein NFS-Server hauptsächlich kleine und nicht zusammengehörige Schreibaufträge erhält, kann dieses Feature aber stören und die Performance drücken. Für diesen Fall ist diese Option no_wdelay gedacht um es auszuschalten. Der voreingestellte Wert ist wdelay,

nohide

Diese Option basiert auf der gleichnamigen Option von IRIX-NFS. Wenn ein Server zwei Dateisysteme exportiert, von denen eins in’s andere gemountet ist, muß der Client normalerweise explizit beide Dateisysteme mounten um auf sie Zugriff zu bekommen. Wenn er nur das Elternsystem mountet, bekommt er nur ein leeres Verzeichnis zu sehen, wo eigentlich das andere Dateisystem gemoutet wäre. Dieses andere System ist also „versteckt“ oder engl. „hidden“.Wenn die nohide Option gesetzt ist, wird das Dateisystem, auf das sie gesetzt ist, nicht versteckt und ein entsprechend authorisierter Client kann von einem ins andere Dateisystem wechseln, ohne die Veränderung zu bemerken.

Allerdings haben einige NFS-Clients Schwierigkeiten mit dieser Situation, weil es dann z.B. möglich wird, daß zwei Dateien in einem scheinbaren Dateisystem ein und die selbe INODE Nummer benutzen.

Die nohide Option hat ihren Effekt nur für die Angabe einzelner Hosts als Clients. Mit Angaben von Netzgruppen, Sumnetzmasken oder Jokerzeichen arbeitet sie nicht verlässlich zusammen.

Die Option kann in manchen Fällen sehr nützlich sein, sollte aber immer mit Vorsicht benutzt werden. Grundsätzlich sollte vor dem Einsatz geklärt werden, daß die verwendeten NFS-Clients mit der Technik umgehen können.

Die Option kann explizit mit hide ausgeschaltet werden.

no_subtree_check

Diese Option schaltet das „Subtree-Checking“, also die Überprüfung von Unterverzeichnisbäumen ab. Das hat zwar eine leichte Verringerung der Sicherheit zur Folge, kann aber die Verlässlichkeit unter Umständen erhöhen.Wenn ein Unterverzeichnis eines Dateisystems freigegeben (exportiert) wird, aber das ganze Dateisystem nicht, muß der NFS Server jedesmal, wenn er eine Anfrage bekommt nicht nur überprüfen, ob die gewünschte Datei in dem Dateisystem liegt (einfach), sondern auch, ob sie tatsächlich in dem Unterverzeichnis liegt (schwieriger). Diese Überprüfung wird subtree_check genannt.

Um diese Überprüfung durchzuführen, muß der Server einige Informationen über die Position der Datei im Dateisystem in der Filehandle integrieren, die an den Client weitergegeben wird. Das kann zu Problemen beim Zugriff auf Dateien führen, die umbenannt werden, während sie noch von einem Client geöffnet sind. (Obwohl es in vielen einfachen Fällen weiter funktioniert).

Subtree_checking wird auch benützt, um sicherzustellen, daß Dateien in Verzeichnissen auf die nur root Zugriff hat nur zugreifbar sind, wenn das Dateisystem mit der no_root_squash Option (siehe unten) exportiert wurde, auch wenn die Datei selbst weniger restriktive Zugriffsmodi hat.

Als genereller Hinweis mag gelten, daß ein Home-Verzeichnis Dateibaum, der normalerweise von seiner Wurzel aus exportiert wird, und auf dem häufig Dateien umbenannt werden, ohne subtree_checking exportiert werden sollte. Ein Dateisystem, das größtenteils ReadOnly ist, und auf dem zumindest selten Dateien umbenannt werden (z.B. /usr oder /var), und aus dem Unterverzeichnisse exportiert werden, sollte mit subtree_checking versehen werden.

Die Voreinstellung, daß der subtree_check aktiviert ist, kann auch explizit mit subtree_check ausgedrückt werden.

insecure_locks

no_auth_nlm

Diese Option (die beiden sind Synonyme) weist den NFS-Server an, bei Dateisperranfragen (locking, z.B. Nachfragen, die das NLM Protokoll benutzen) keine Authentifizierung zu verlangen. Normalerweise würde der NFS-Server einen Sperrmechanismus verlangen, um einen Berechtigungsnachweis für User zu verwalten, die Lesezugriff auf die Datei haben. Mit dieser Option werden keine Zugriffsüberprüfungen gemacht.Alte NFS-Client Implementationen haben keine Berechtigungsnachweise zusammen mit Sperrnachfragen verschickt und es existieren viele aktuelle NFS-Clients, die auf diesen alten Architekturen basieren. Dieser Flag sollte also benutzt werden, wenn auffällt, daß nur Dateien gesperrt werden können, die von allen Usern lesbar sind.

Die voreingestellte Eigenschaft, Authentifizierung für NLM-Nachfragen zu verlangen, kann explizit mit einem der Synonymen auth_nlm oder secure_locks angegeben werden.

UserID-Mapping

Der NFS-Daemon nfsd arbeitet bei der Frage der Zugriffskontrolle auf der Serverseite mit den User- und GruppenIDs (UID und GID) die bei jeder NFS-Nachfrage mitgeschickt werden. Der normale Vorgang, den ein User erwarten würde ist, daß er Zugriff auf seine Dateien auf dem Server genauso hätte, wie auf einem lokalen Dateisystem. Das erfordert, daß die selben User- und GruppenIDs auf Server und Client benutzt werden. Das ist nicht immer der Fall und kann auch nicht immer gewährleistet werden.

Sehr häufig kann nicht gewünscht werden, daß der root-User einer Client-Maschine auch als root auf dem Server behandelt werden soll. Um damit umzugehen, wird die UserID 0 normalerweise auf eine andere UserID abgebildet, der sogenannten anonymen UserID. Diese Verhaltensweise wird root_squashing genannt und ist die voreingestellte Arbeitsweise. Sie kann mit no_root_squash abgeschaltet werden.

Voreingestellt ist, daß exportfs eine User- und GruppenID von -2 (oder vorzeichenlos eben 65534) für diesen Zugriff benutzt. Diese Werte können mit den Optionen anonuid und anongid verändert werden. Schließlich können auch alle Useranfragen auf diese anonymen IDs abgebildet werden, indem die Option all_squash verwendet wird.

Hier folgt die komplette Liste aller Optionen für das User-Mapping:

root_squash

Anfragen der User/GruppenID 0 werden auf die anonyme User/GruppenID abgebildet. Beachten Sie, daß damit andere mächtige UserIDs wie etwa bin nicht geändert werden. Diese Option ist voreingestellt.

no_root_squash

Das root_squashing wird abgeschaltet. Diese Option ist hauptsächlich für plattenlose Clients geeignet.

all_squash

Alle UserIDs werden auf die anonymen IDs abgebildet. Nützlich für NFS-exportierte öffentliche FTP-Verzeichnisse oder News-Spoolverzeichnisse. Die gegenteilige Option ist no_all_squash, die die voreingestellte Methode darstellt.

anonuid und anongid

Diese Option setzt die anonyme User- und GruppenID explizit auf die angegebenen Werte. Diese Option ist primär für PC/NFS Clients gedacht, wo davon ausgegangen wird, daß alle Nachfragen von einem bestimmten Rechner immer von einer Person kommen. Als Beispiel dient der Eintrag im folgenden Beispiel-Abschnitt für /home/joe, bei dem alle Nachfragen auf die UserID 150 abbilden, die natürlich dann dem User joe gehören sollte.

Beispiel

       # Beispiel einer /etc/exports Datei
       /               master(rw) trusty(rw,no_root_squash)
       /projects       proj*.local.domain(rw)
       /usr            *.local.domain(ro) @trusted(rw)
       /home/joe       pc001(rw,all_squash,anonuid=150,anongid=100)
       /pub            (ro,insecure,all_squash)

Die erste Zeile exportiert das gesamte Dateisystem an die Maschinen master und trusty. Zusätzlich zum Schreibrecht wird auf dem Rechner trusty das root_squashing ausgeschaltet, root auf trusty darf also mit der UserID 0 auf dem freigegebenen System arbeiten.

Die zweite und dritte Zeile zeigen Beispiele, die Jokerzeichen und Netzgruppen (das ist der Eintrag @trusted) verwenden.

Die vierte Zeile zeigt einen Eintrag für PC-NFS, wie oben beschrieben.

Zeile 5 exportiert das öffentliche FTP-Verzeichnis an alle Rechner der Welt unter der anonymen UserID. Die insecure Option erlaubt auch Clients den Zugriff, deren NFS-Implementation keinen reservierten Port benutzen.