Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Wie Sicherheitstypen die Client-Zugriffsebenen bestimmen

Beitragende

Der Sicherheitstyp, mit dem der Client authentifiziert wurde, spielt eine besondere Rolle in den Exportregeln. Sie müssen verstehen, wie der Sicherheitstyp die Zugriffsebenen bestimmt, die der Client zu einem Volume oder qtree erhält.

Die drei möglichen Zugriffsebenen sind wie folgt:

  1. Schreibgeschützt

  2. Lesen und schreiben

  3. Superuser (für Clients mit Benutzer-ID 0)

Da die Zugriffsebene nach Sicherheitstyp in dieser Reihenfolge ausgewertet wird, müssen Sie beim Erstellen von Parametern auf Zugriffsebene in Exportregeln folgende Regeln beachten:

Damit ein Client die Zugriffsebene abrufen kann…​ Diese Zugriffsparameter müssen dem Sicherheitstyp des Clients entsprechen…​

Normaler Benutzer schreibgeschützt

Schreibgeschützt (-rorule)

Normaler Benutzer Lese-/Schreibzugriff

Read-only(-rorule) und read-write (-rwrule)

Schreibgeschützt für Superuser

Read-only (-rorule) und -superuser

Superuser lesen und schreiben

Read-only (-rorule) und read-write (-rwrule) und -superuser

Die folgenden Sicherheitstypen sind für jeden der folgenden drei Zugriffsparameter gültig:

  • any

  • none

  • never

    Dieser Sicherheitstyp ist für die Verwendung mit dem -superuser Parameter nicht gültig.

  • krb5

  • krb5i

  • krb5p

  • ntlm

  • sys

Beim Abgleich des Sicherheitstyps eines Clients mit jedem der drei Zugriffsparameter gibt es drei mögliche Ergebnisse:

Falls der Sicherheitstyp des Clients…​ Dann der Client…​

Stimmt mit dem im Zugriffsparameter angegebenen überein.

Erhält Zugriff auf dieses Level mit eigener Benutzer-ID.

Stimmt nicht mit dem angegebenen überein, aber der Zugriffsparameter enthält die Option none.

Erhält Zugriff für diese Ebene, jedoch als anonymer Benutzer mit der vom -anon Parameter angegebenen Benutzer-ID.

Stimmt nicht mit dem angegebenen überein und der Zugriffsparameter enthält nicht die Option none.

Erhält keinen Zugriff auf diese Ebene.Dies gilt nicht für den -superuser Parameter, da er immer none auch dann einbezieht, wenn er nicht angegeben ist.

Beispiel

Die Exportrichtlinie enthält eine Exportregel mit den folgenden Parametern:

  • -protocol nfs3

  • -clientmatch 10.1.16.0/255.255.255.0

  • -rorule any

  • -rwrule sys,krb5

  • -superuser krb5

Client #1 hat die IP-Adresse 10.1.16.207, hat Benutzer-ID 0, sendet eine Zugriffsanfrage über das NFSv3-Protokoll und authentifiziert mit Kerberos v5.

Client #2 hat die IP-Adresse 10.1.16.211, hat Benutzer-ID 0, sendet eine Zugriffsanfrage über das NFSv3-Protokoll und authentifiziert mit AUTH_SYS.

Client #3 hat die IP-Adresse 10.1.16.234, hat Benutzer-ID 0, sendet eine Zugriffsanforderung über das NFSv3-Protokoll und authentifiziert nicht (AUTH_NONE).

Das Client-Zugriffsprotokoll und die IP-Adresse stimmen mit allen drei Clients überein. Der schreibgeschützte Parameter ermöglicht den schreibgeschützten Zugriff auf alle Clients unabhängig vom Sicherheitstyp. Der Lese-Schreib-Parameter ermöglicht den Lese-Schreib-Zugriff auf Clients mit eigener Benutzer-ID, die mit AUTH_SYS oder Kerberos v5 authentifiziert wurden. Der Superuser-Parameter ermöglicht Superuser-Zugriff auf Clients mit Benutzer-ID 0, die mit Kerberos v5 authentifiziert wurden.

Client #1 erhält daher Lese-/Schreibzugriff für Superuser, da er alle drei Zugriffsparameter einordnet. Client #2 erhält Lese-/Schreibzugriff, aber keinen Superuser-Zugriff. Client #3 erhält nur Lesezugriff, aber keinen Superuser-Zugriff.