sale e pepe

Die Würze des Admin-Daseins

Inhalt

NFS Security mit OpenSolaris Client und Linux Server

Bei uns am RRZE ist das Problem aufgetaucht, dass ein Benutzer auf einem OpenSolaris NFS Client nicht auf sein Home auf einem Linux NFS Server zugreifen konnte. Nur Dateien die für jedermann (nobody) zugreifbar waren, konnten gelesen werden. Der Mount dieses speziellen Home Verzeichnisses wurde über den Automounter gemacht und funktioniert auf Solaris 10 einwandfrei.

Ein Mounten von Hand mit nfsv2 hat ebenfalls das gewünschte Resultat gebracht und mit Expliziter Angabe des security modes (-o sec=sys) hat es dann auch geklappt. Nur: woran liegt das und wie kann der Mount über den Automounter gemacht werden ohne diese Option in der automounter map mit anzugeben (was potenziell an anderer Stelle Probleme hätte bereiten können)?

Ein paar Nachforschungen haben ergeben, dass das Problem in der Linux NFS Server Implementierung liegt. „Buggy“ wäre das falsche Wort, ich würde sagen – missinterpretiert. Kurz gesagt sagt die NFS v3 Spezifikation, dass beim Initiieren der Kommunikation der Server dem Client ein Array mit den von ihm unterstützten Security modes schickt. Der Client sucht sich nun die erste aus, die er selbst unterstützt. Linux sendet aber als ersten Modus den Modus „NONE“, was soviel bedeutet, dass kein Mapping von Benutzern gemacht wird. Ein NFS Client/Benutzer kann nur das lesen, was für „other“ lesbar ist. Somit versucht OpenSolaris auch den ersten Modus den es kennt zu verwenden. Also klappt das mit dem UID/GID Mapping auf /etc/passwd bzw. /etc/group nicht. Dieses wäre nämlich sec=sys (also Security Mode AUTH_SYSTEM). Abhilfe schafft, dem OpenSolaris einfach den Security Mode „NONE“ abzugewöhnen (der sowieso so gut wie nie eingesetzt wird). Dazu in der Datei /etc/nfssec.conf die eine Zeile mit AUTH_NONE auskommentieren und den NFS Client Dienst neu starten. Und schon klappt’s auch mit den Linux NFS Servern.

Wieso OpenSolaris sich plötzlich strikter an die NFSv3 Spezifikationen hält als Solaris 10 ist ein anderes Thema. Fakt ist, dass die Linux Jungs da mal wieder was auf ihre Art und Weise implementiert haben. Denn neben Linux hat ja sowieso keiner eine Daseinsberechtigung. Manchmal erinnert mich das an Micro$oft…

2 Kommentare zu “NFS Security mit OpenSolaris Client und Linux Server

  1. Michael Meier sagt:

    Also IMO ist die Interpretation von Linux da voellig logisch und richtig. Es bietet zwei Moeglichkeiten an, AUTH_NONE und AUTH_SYSTEM, und es unterstuetzt auch beide. Es ist ja nicht so dass der Server behaupten wuerde „ich kann AUTH_NONE“, und wenn du dann mit AUTH_NONE zugreifst das nicht versteht. Er implementiert das AUTH_NONE ja voellig korrekt.
    Das ist nicht gross anders als sagen wir eine Webseite, wie z.B. dieses Blog, die man unauthentifiziert (AUTH_NONE) oder nach login (AUTH_SYSTEM) besuchen kann. Unauthentifiziert hat man eben nicht viele rechte, man kann hier z.B. nur lesen, nach Login dann auch kommentieren oder selber bloggen.

    Nicht verstehen kann ich dagegen, warum die Opensolaris-Frickler eine nfssec.conf Einstellung anbieten, um einen default auszuwaehlen, der dann auch schoen wie folgt in der Defaultconfig drin steht:
    default 1 – – – # default is AUTH_SYS
    aber halt ignoriert wird. _Ich_ und vermutlich jeder andere Mensch mit Verstand wuerde erwarten, dass dieser Eintrag den bestimmt der ausgewaehlt wird, wenn mehrere Moeglichkeiten zur Wahl stehen. Wenn ich mir anschaue was tante gugel so ausspuckt, ist ihnen das Problem inzwischen wohl auch aufgefallen, und sie wollen es beheben – nicht etwa dadurch dass sie das verhalten logisch nachvollziehbar machen, sondern dadurch dass sie dokumentieren dass es nicht funktioniert wie man erwartet…

  2. Gregor Longariva sagt:

    Ja Michael, wir wissen es: Linux hat immer recht. Und wenn nicht – hat es trotzdem recht.
    SCNR 😉

Die Kommentarfunktion ist geschlossen.