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. Google Cloud NetApp Volumes unterstützen weder POSIX ACLs noch erweiterte Attribute (wie chattr), granulare ACLs sind also nur in den folgenden Szenarien mit NFSv3 möglich:

Beide Methoden erfordern eine LDAP-Verbindung für die UNIX-Identitätsverwaltung und eine gültige UNIX-Benutzer- und Gruppeninformation (siehe Abschnitt "„LDAP“") und sind nur bei NetApp-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 mit NFSv3-Mounts zu verwenden, müssen Sie als Protokolltyp auswählen Both (NFSv3/NFSv4.1).

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 Google Cloud NetApp Volumes erweiterte Gruppenunterstützung, um die maximal unterstützten Gruppen auf bis zu 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 "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 derartige Sicherheitslücken zu vermeiden, stehen Google Cloud NetApp Volumes einige Optionen zur Verfügung.

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).

Google Cloud NetApp Volumes unterstützt NFSv4.x ACLs und bietet klare Vorteile gegenüber normalen POSIX-ähnlichen Berechtigungen wie die folgenden:

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 eines SETATTR-Vorgangs eine NFSv4.1-ACL auf eine Datei festlegt, legt Google Cloud NetApp Volumes diese ACL auf das Objekt fest und ersetzt so 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 im Verlauf einer GETATTR-Operation eine NFSv4.1-ACL für eine Datei erhält, liest Google Cloud NetApp Volumes die dem Objekt zugeordnete NFSv4.1-ACL. Es 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 Berechtigungsebene zu steuern, auf der Dateien und Ordner ohne Administratoreingriff in einem Verzeichnis erstellt werden. Standardmäßig können in Google Cloud NetApp Volumes umask geerbte ACLs außer Kraft setzen, was erwartetes Verhalten nach "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 Benutzername und der Gruppenname des NFSv4.1-Clients einen Namensstring an und sendet ihn an die Instanz von Google Cloud NetApp Volumes. Wenn dieser Benutzername/Gruppenname und die ID-String-Kombination nicht übereinstimmen, wird der Benutzer und/oder die Gruppe auf den Standardbenutzer Niemand gequetscht, der in der Datei auf dem Client angegeben /etc/idmapd.conf ist.

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 Abhängigkeiten des Namensservers wie LDAP-Server erforderlich, um für eine Client-übergreifende Konsistenz und Google Cloud NetApp Volumes eine ordnungsgemäße Auflösung der Identität von Benutzer- und Gruppennamen zu gewährleisten.

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

Wenn LDAP in Google Cloud NetApp Volumes aktiviert ist, automatisiert Google Cloud NetApp Volumes die NFS-ID-Domäne, um zu ändern, was für die Suchdomäne im DNS konfiguriert ist, und Clients müssen nicht geändert werden, es sei denn, sie verwenden andere DNS-Domain-Suchnamen.

Wenn Google Cloud NetApp Volumes einen Benutzernamen oder Gruppennamen in lokalen Dateien oder LDAP auflösen können, wird der Domänenstring verwendet und die nicht übereinstimmenden Domänen-IDs an niemanden vergeben. Wenn Google Cloud NetApp-Volumes keinen Benutzernamen oder Gruppennamen in lokalen Dateien oder LDAP finden können, wird der numerische ID-Wert verwendet, und der NFS-Client löst den Namen ordnungsgemäß auf (dies ähnelt dem NFSv3-Verhalten).

Ohne die NFSv4.1 ID-Domäne des Kunden zu ändern, die mit dem Google Cloud NetApp Volumes-Volume übereinstimmt, sehen Sie das folgende 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 Folgendes mit Google Cloud NetApp Volumes 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, müssen Google Cloud NetApp Volumes user1@CVSDEMO.LOCAL finden können (uid 1234, gid 1234). Wenn der Benutzer in Google Cloud NetApp Volumes USER1@CVSDEMO.LOCAL ist, dann stimmt er nicht überein (Großbuchstaben USER1 versus Kleinbuchstaben USER1). In vielen Fällen können Sie Folgendes in der Meldungsdatei auf dem Client sehen:

Der Client und der Server müssen sich beide damit einverstanden erklären, dass ein Benutzer tatsächlich der Benutzer ist, den er vorgibt zu sein. Daher müssen Sie Folgendes überprüfen, um sicherzustellen, dass der Benutzer, den der Client sieht, über dieselben Informationen verfügt wie der Benutzer, den Google Cloud NetApp Volumes sieht.

In fast allen Fällen, wenn Sie in Benutzer- und Gruppenlisten von Clients sehen nobody, ist das Problem die Übersetzung von Benutzer- oder Gruppennamen-Domänen-IDs zwischen Google Cloud NetApp Volumes und dem NFS-Client. Um dieses Szenario zu vermeiden, verwenden Sie LDAP zum Auflösen von Benutzer- und Gruppeninformationen zwischen Clients und Google Cloud NetApp Volumes.

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 ist beispielsweise die Ausgabe des Befehls nach einem Benutzer, der vom Client gefunden werden kann, und Google Cloud NetApp-Volumes greifen auf einen NFSv4.x-Mount zu:

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).