Mode-Bit-Berechtigungen decken nur Besitzer, Gruppe und alle anderen in der Semantik ab. Dies bedeutet, dass für Basic NFSv3 keine granularen Benutzerzugriffskontrollen vorhanden sind. Cloud Volumes Service unterstützt weder POSIX ACLs noch erweiterte Attribute (wie z. B. Chattr), sodass granulare ACLs nur in den folgenden Szenarien mit NFSv3 möglich sind:

Beide Methoden erfordern eine LDAP-Verbindung für das UNIX-Identitätsmanagement und eine gültige UNIX-Benutzer- und Gruppeninformationen (siehe Abschnitt "„LDAP“") Und sind nur mit CVS-Performance Instanzen verfügbar. Um Volumes im NTFS-Sicherheitsstil mit NFS zu verwenden, müssen Sie Dual-Protokoll (SMB und NFSv3) oder Dual-Protokoll (SMB und NFSv4.1) verwenden, auch wenn keine SMB-Verbindungen hergestellt werden. Um NFSv4.1 ACLs für NFSv3-Mounts zu verwenden, müssen Sie auswählen Both (NFSv3/NFSv4.1) Als Protokolltyp.

Normale UNIX Modus Bits bieten nicht die gleiche Granularitätsebene in Berechtigungen, die NTFS oder NFSv4.x ACLs bieten. In der folgenden Tabelle wird die Berechtigungsgranularität zwischen NFSv3-Modus-Bits und NFSv4.1 ACLs verglichen. Informationen zu NFSv4.1 ACLs finden Sie unter "nfs4_acl – NFSv4 Access Control-Listen".

Schließlich ist die NFS-Gruppenmitgliedschaft (sowohl in NFSv3 als AUCH NFSV4.x) auf ein Standardlimit von 16 für AUTH_SYS begrenzt, gemäß den RPC-Paketlimits. NFS Kerberos bietet bis zu 32 Gruppen und NFSv4 ACLs entfernen die Beschränkung durch granulare Benutzer- und Gruppen-ACLs (bis zu 1024 Einträge pro ACE).

Darüber hinaus bietet Cloud Volumes Service erweiterte Gruppen-Support, um die maximal unterstützten Gruppen auf 32 zu erweitern. Dazu ist eine LDAP-Verbindung zu einem LDAP-Server erforderlich, der gültige UNIX-Benutzer- und Gruppenidentitäten enthält. Weitere Informationen zur Konfiguration finden Sie unter "Erstellen und Managen von NFS-Volumes" In der Google-Dokumentation.

Bei NFSv3 müssen Client und Server niemals bestätigen, dass der Benutzer, der einen Lese- oder Schreibversuch mit einer numerischen ID versucht, ein gültiger Benutzer ist; er ist einfach implizit vertrauenswürdig. Das öffnet das Dateisystem bis zu potenziellen Verstößen, indem es einfach eine numerische ID vortäuscht. Um Sicherheitslücken wie diese zu verhindern, gibt es einige Optionen für Cloud Volumes Service.

Letztendlich ist die NFS-Sicherheit auf das beschränkt, was die Protokollversion verwendet, die Sie Angebote verwenden. NFSv3, obwohl mehr Performance im Allgemeinen als NFSv4.1, nicht dasselbe Maß an Sicherheit bietet.

Aufgrund der zusätzlichen Sicherheitsfunktionen in NFSv4.1 sind einige externe Abhängigkeiten beteiligt, die nicht für die Verwendung von NFSv3 benötigt wurden (ähnlich wie SMB Abhängigkeiten wie Active Directory erfordert).

Cloud Volumes Service bietet Unterstützung für NFSv4.x ACLs, die bestimmte Vorteile gegenüber normalen POSIX-Berechtigungen bieten, wie z. B.:

NFSv4 ACLs unterscheiden sich von Windows ACLs auf Dateiebene (NTFS ACLs), haben aber ähnliche Funktionen. In NAS-Umgebungen mit mehreren Protokollen, wenn NFSv4.1 ACLs vorhanden sind und Sie Dual-Protokoll-Zugriff verwenden (NFS und SMB auf den gleichen Datensätzen), werden Clients mit SMB2.0 und später nicht in der Lage sein, ACLs von Windows-Sicherheitregisterkarten anzuzeigen oder zu verwalten.

Als Referenz sind folgende Begriffe definiert:

Wenn ein Client während einer SETATTR-Operation eine NFSv4.1-ACL für eine Datei setzt, setzt Cloud Volumes Service diese ACL für das Objekt und ersetzt eine vorhandene ACL. Wenn es keine ACL für eine Datei gibt, werden die Modus-Berechtigungen für die Datei von EIGENTÜMER@, GROUP@ und EVERYONE@ berechnet. Wenn SUID/SGID/STICKY Bits in der Datei vorhanden sind, sind diese nicht betroffen.

Wenn ein Client während einer GETATTR Operation eine NFSv4.1 ACL für eine Datei erhält, liest Cloud Volumes Service die mit dem Objekt verknüpfte NFSv4.1 ACL, erstellt eine Liste von Aces und gibt die Liste an den Client zurück. Wenn die Datei über eine NT ACL oder Mode Bits verfügt, wird eine ACL aus Modus-Bits erstellt und an den Client zurückgegeben.

Der Zugriff wird verweigert, wenn in der ACL ein ACE VERWEIGERN vorhanden ist; der Zugriff wird gewährt, wenn ACE ZULASSEN vorhanden ist. Der Zugang wird jedoch auch verweigert, wenn keines der Asse in der ACL vorhanden ist.

Ein Sicherheitsdeskriptor besteht aus einer Sicherheits-ACL (SACL) und einer Ermessensdatei (Discretionary ACL, DACL). Bei der Ausführung von NFSv4.1 mit CIFS/SMB ist die DACL 1-to-One-Zuordnung mit NFSv4 und CIFS. Die DACL besteht aus DEM ERLAUBEN und DEN LEUGNEN Assen.

Wenn ein einfaches chmod Wird auf einer Datei oder einem Ordner mit NFSv4.1 ACLs gesetzt ausgeführt, bestehende Benutzer- und Gruppen-ACLs bleiben erhalten, aber der STANDARDEIGENTÜMER@, GROUP@, EVERYONE@ ACLs werden geändert.

Ein Client, der NFSv4.1 ACLs verwendet, kann ACLs für Dateien und Verzeichnisse auf dem System festlegen und anzeigen. Wenn eine neue Datei oder ein Unterverzeichnis in einem Verzeichnis erstellt wird, das über eine ACL verfügt, erbt dieses Objekt alle Asse in der ACL, die mit dem entsprechenden gekennzeichnet wurden "Ervererbungsflaggen".

Wenn eine Datei oder ein Verzeichnis über eine NFSv4.1-ACL verfügt, wird diese ACL verwendet, um den Zugriff zu steuern, unabhängig davon, welches Protokoll für den Zugriff auf die Datei oder das Verzeichnis verwendet wird.

Dateien und Verzeichnisse erben Asse von NFSv4 ACLs auf übergeordneten Verzeichnissen (möglicherweise mit entsprechenden Änderungen), solange die Asse mit den korrekten Vererbung-Flags markiert wurden.

Wenn eine Datei oder ein Verzeichnis als Ergebnis einer NFSv4-Anforderung erstellt wird, hängt die ACL für die resultierende Datei oder das Verzeichnis davon ab, ob die Dateierstellungsanforderung eine ACL oder nur standardmäßige UNIX-Dateizugriffsberechtigungen enthält. Die ACL hängt auch davon ab, ob das übergeordnete Verzeichnis über eine ACL verfügt.

Die Berechtigungen für NFSv4.1 ACLs verwenden eine Reihe von Groß- und Kleinbuchstaben (z. B. rxtncy) Um den Zugriff zu steuern. Weitere Informationen zu diesen Buchstabenwerten finden Sie unter "WIE: Verwenden Sie NFSv4 ACL".

"NFSv4 ACLs bieten die Möglichkeit, eine ACL-Vererbung anzubieten". ACL-Vererbung bedeutet, dass Dateien oder Ordner, die unter Objekten mit NFSv4.1 ACLs-Satz erstellt wurden, die ACLs basierend auf der Konfiguration des erben können "ACL-Vererbungskennzeichnung".

"Umfragen" Wird verwendet, um die Berechtigungsstufe zu steuern, auf der Dateien und Ordner in einem Verzeichnis ohne Administratorinteraktion erstellt werden. Standardmäßig können mit Cloud Volumes Service übernommene ACLs überschrieben werden. Dies ist ein erwartetes Verhalten wie per "RFC 5661".

NFSv4.1 ACLs haben bestimmte Formatierung. Das folgende Beispiel ist ein ACE-Satz für eine Datei:

Das vorangegangene Beispiel folgt den Richtlinien im ACL-Format von:

Einen Typ von A Bedeutet „Zulassen“. Die Erben-Flags werden in diesem Fall nicht festgelegt, da der Principal keine Gruppe ist und keine Vererbung beinhaltet. Da es sich bei ACE nicht um EINEN AUDIT-Eintrag handelt, müssen die Audit-Flags nicht festgelegt werden. Weitere Informationen zu NFSv4.1 ACLs finden Sie unter "http://linux.die.net/man/5/nfs4_acl".

Wenn die NFSv4.1 ACL nicht richtig eingestellt ist (oder eine Namenszeichenfolge nicht vom Client und Server aufgelöst werden kann), verhält sich die ACL möglicherweise nicht wie erwartet. Andernfalls kann die ACL-Änderung nicht angewendet werden und einen Fehler verursacht.

Beispielfehler sind:

Die Berechtigungen in NFSv4.1 können explizite DENY-Attribute für EIGENTÜMER, GRUPPE und ALLE enthalten. Das liegt daran, dass NFSv4.1 ACLs Standard-Deny sind. Dies bedeutet, dass, wenn eine ACL nicht ausdrücklich von einem ACE gewährt wird, sie verweigert wird. Explizite DENY-Attribute überschreiben alle ZUGRIFFSOPTIONEN, explizit oder nicht.

DENY Aces werden mit einem Attribut-Tag von festgelegt D.

Im folgenden Beispiel ist DER GRUPPE@ alle Lese- und Ausführungsberechtigungen erlaubt, aber der gesamte Schreibzugriff wird verweigert.

DENY Aces sollten möglichst vermieden werden, da sie verwirrend und kompliziert sein können; ACLS, die nicht explizit definiert sind, WERDEN implizit verweigert. Wenn Asse VERWEIGERN festgelegt sind, wird Benutzern möglicherweise der Zugriff verweigert, wenn sie erwarten, dass ihnen Zugriff gewährt wird.

Der vorhergehende Satz von Assen entspricht 755 im Modus Bits, was bedeutet:

Selbst wenn die Berechtigungen auf das Äquivalent von 775 angepasst werden, kann der Zugriff aufgrund der expliziten DENY-Einstellung für ALLE verweigert werden.

NFSv4.1 nutzt die ID-Domain-Mapping-Logik als Sicherheitsschicht, um zu überprüfen, ob ein Benutzer, der auf einen NFSv4.1-Mount zugreifen möchte, tatsächlich derjenige ist, der behauptet. In diesen Fällen hängt der vom NFSv4.1-Client stammende Benutzername und Gruppenname eine Namenszeichenfolge an und sendet sie an die Cloud Volumes Service-Instanz. Wenn diese Kombination aus Benutzername/Gruppenname und ID-Zeichenfolge nicht übereinstimmt, dann wird der Benutzer und/oder die Gruppe auf den Standard-niemand-Benutzer gesetzt, der im angegeben wurde /etc/idmapd.conf Datei auf dem Client.

Diese ID-Zeichenfolge ist eine Voraussetzung für die ordnungsgemäße Einhaltung von Berechtigungen, insbesondere wenn NFSv4.1 ACLs und/oder Kerberos verwendet werden. Daher sind Serverabhängigkeiten des Nameservice wie LDAP-Server erforderlich, um die Konsistenz zwischen Clients und Cloud Volumes Service für eine ordnungsgemäße Identitätsauflösung von Benutzer und Gruppennamen zu gewährleisten.

Cloud Volumes Service verwendet einen statischen Standard-ID-Domänennamen von defaultv4iddomain.com. NFS-Clients verwenden standardmäßig den DNS-Domain-Namen für seine ID-Domain-Namen-Einstellungen. Sie können den ID-Domain-Namen in jedoch manuell anpassen /etc/idmapd.conf.

Wenn LDAP in Cloud Volumes Service aktiviert ist, dann Cloud Volumes Service automatisiert die NFS ID Domain zu ändern, was für die Suche Domain in DNS konfiguriert ist und Clients nicht geändert werden müssen, es sei denn sie verwenden unterschiedliche DNS Domain Suchnamen.

Wenn Cloud Volumes Service einen Benutzernamen oder Gruppennamen in lokalen Dateien oder LDAP auflösen kann, wird die Domänenzeichenfolge verwendet und nicht übereinstimmende Domänen-IDs Squash an niemand. Wenn Cloud Volumes Service einen Benutzernamen oder Gruppennamen nicht in lokalen Dateien oder LDAP finden kann, wird der numerische ID-Wert verwendet, und der NFS-Client löst den Namen richtig aus (dies entspricht dem NFSv3-Verhalten).

Ohne die NFSv4.1 ID-Domäne des Clients zu ändern, um mit dem zu übereinstimmen, was der Cloud Volumes Service-Datenträger verwendet, sehen Sie folgendes Verhalten:

Die Ergebnisse des vorhergehenden Szenarios:

Wenn die Client- und Server-ID-Domänen übereinstimmen, wird die gleiche Dateiliste angezeigt:

Weitere Informationen zu diesem Thema und wie man es löst, finden Sie im Abschnitt „NFSv4.1 und der niemand-Benutzer/Gruppe.“

Wenn Sie Kerberos mit NFS verwenden möchten, müssen Sie für Cloud Volumes Service Folgendes haben:

Eines der häufigsten Probleme bei einer NFSv4.1-Konfiguration ist, wenn eine Datei oder ein Ordner in einer Auflistung mit angezeigt wird ls Als im Besitz des user:group Kombination von nobody:nobody.

Beispiel:

Und die numerische ID lautet 99.

In manchen Fällen wird die Datei möglicherweise den korrekten Eigentümer, aber angezeigt nobody Als Gruppe.

Wer ist niemand?

Der nobody Benutzer in NFSv4.1 unterscheidet sich von dem nfsnobody Benutzer: Sie können anzeigen, wie ein NFS Client jeden Benutzer sieht, indem Sie die ausführen id Befehl:

Mit NFSv4.1, das nobody Der von definierte Standardbenutzer ist der Benutzer idmapd.conf Datei und kann als jeder Benutzer definiert werden, den Sie verwenden möchten.

Warum passiert das?

Da Sicherheit durch Namenszeichenzuordnung ein Schlüsseltenet von NFSv4.1-Operationen ist, ist das Standardverhalten, wenn eine Namenszeichenfolge nicht richtig übereinstimmt, dass der Benutzer zu einem Squash, der normalerweise keinen Zugriff auf Dateien und Ordner hat, die Benutzer und Gruppen gehören.

Wenn Sie sehen nobody Für den Benutzer und/oder die Gruppe in Dateilisten bedeutet dies im Allgemeinen, dass etwas in NFSv4.1 falsch konfiguriert ist. Hier kann die Empfindlichkeit des Falles ins Spiel kommen.

Wenn z. B. user1@CVSDEMO.LOCAL (uid 1234, gid 1234) auf einen Export zugreift, muss Cloud Volumes Service user1@CVSDEMO.LOCAL (uid 1234, gid 1234) finden können. Wenn der Benutzer in Cloud Volumes Service ist USER1@CVSDEMO.LOCAL, dann wird es nicht übereinstimmen (GROSSUSER1 vs. Kleinbuchstaben user1). In vielen Fällen können Sie Folgendes in der Meldungsdatei auf dem Client sehen:

Der Client und Server müssen beide zustimmen, dass ein Benutzer tatsächlich der Meinung ist, dass er sein soll. Sie müssen daher Folgendes überprüfen, um sicherzustellen, dass der Benutzer, der den Client sieht, dieselben Informationen hat wie der Benutzer, den Cloud Volumes Service sieht.

In fast allen Fällen, wenn Sie sehen nobody Bei Benutzer- und Gruppenlisten von Clients handelt es sich um das Problem der Übersetzung von Benutzer- oder Gruppennamen-Domänen-ID zwischen Cloud Volumes Service und dem NFS-Client. Um dieses Szenario zu vermeiden, verwenden Sie LDAP, um Benutzer- und Gruppeninformationen zwischen Clients und Cloud Volumes Service aufzulösen.

Wenn Sie NFSv4.1 verwenden, gibt es ein Name-String-Mapping, das während NFS-Vorgängen stattfindet, wie zuvor beschrieben.

Zusätzlich zu verwenden /var/log/messages Um ein Problem mit NFSv4-IDs zu finden, können Sie das verwenden "Nfsidmap -l" Befehl auf dem NFS Client, um anzuzeigen, welche Benutzernamen der NFSv4-Domäne ordnungsgemäß zugeordnet haben.

Dies wird beispielsweise nach einem Benutzer ausgegeben, der vom Client gefunden werden kann und Cloud Volumes Service auf einen NFSv4.x Mount zugreift:

Wenn ein Benutzer, der der NFSv4.1 ID-Domäne nicht ordnungsgemäß zugeordnet ist (in diesem Fall netapp-user) Versucht, auf denselben Mount zuzugreifen und berührt eine Datei, sie sind zugewiesen nobody:nobody, Wie erwartet.

Der nfsidmap -l Ausgabe zeigt den Benutzer an pcuser Im Display, aber nicht netapp-user; Dies ist der anonyme Benutzer in unserer Export-Policy Regel (65534).