Modusbitberechtigungen decken in der Semantik nur den Besitzer, die Gruppe und alle anderen ab. Das bedeutet, dass für das grundlegende NFSv3 keine granularen Benutzerzugriffskontrollen vorhanden sind. Google Cloud NetApp Volumes unterstützt weder POSIX-ACLs noch erweiterte Attribute (wie etwa chattr), daher sind granulare ACLs nur in den folgenden Szenarien mit NFSv3 möglich:

Beide Methoden erfordern eine LDAP-Verbindung für die UNIX-Identitätsverwaltung und gültige UNIX-Benutzer- und Gruppeninformationen (siehe Abschnitt"LDAP" ) und sind nur mit NetApp Volumes-Performance-Instanzen verfügbar. Um Volumes im NTFS-Sicherheitsstil mit NFS zu verwenden, müssen Sie ein Dualprotokoll (SMB und NFSv3) oder ein Dualprotokoll (SMB und NFSv4.1) verwenden, auch wenn keine SMB-Verbindungen hergestellt werden. Um NFSv4.1-ACLs mit NFSv3-Mounts zu verwenden, müssen Sie Both (NFSv3/NFSv4.1) als Protokolltyp.

Reguläre UNIX-Modusbits bieten nicht die gleiche Granularität bei den Berechtigungen wie NTFS- oder NFSv4.x-ACLs. Die folgende Tabelle vergleicht die Berechtigungsgranularität zwischen NFSv3-Modusbits und NFSv4.1-ACLs. Informationen zu NFSv4.1-ACLs finden Sie unter "nfs4_acl – NFSv4-Zugriffskontrolllisten" .

Schließlich ist die NFS-Gruppenmitgliedschaft (sowohl in NFSv3 als auch in NFSV4.x) gemäß den RPC-Paketlimits auf ein Standardmaximum von 16 für AUTH_SYS begrenzt. NFS Kerberos bietet bis zu 32 Gruppen und NFSv4-ACLs heben die Einschränkung durch granulare Benutzer- und Gruppen-ACLs auf (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 erhöhen. Dies erfordert eine LDAP-Verbindung zu einem LDAP-Server, der gültige UNIX-Benutzer- und Gruppenidentitäten enthält. Weitere Informationen zur Konfiguration finden Sie unter "Erstellen und Verwalten von NFS-Volumes" in der Google-Dokumentation.

Bei NFSv3 müssen Client und Server nie bestätigen, dass der Benutzer, der mit einer numerischen ID einen Lese- oder Schreibvorgang versucht, ein gültiger Benutzer ist; ihm wird einfach implizit vertraut. Dadurch wird das Dateisystem durch das einfache Fälschen einer beliebigen numerischen ID für potenzielle Sicherheitsverletzungen anfällig. Um Sicherheitslücken wie diese zu vermeiden, stehen Google Cloud NetApp Volumes einige Optionen zur Verfügung.

Letztendlich ist die NFS-Sicherheit auf das beschränkt, was die von Ihnen verwendete Protokollversion bietet. NFSv3 ist zwar im Allgemeinen leistungsfähiger als NFSv4.1, bietet jedoch nicht das gleiche Maß an Sicherheit.

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

Google Cloud NetApp Volumes bietet Unterstützung für NFSv4.x-ACLs, die gegenüber normalen Berechtigungen im POSIX-Stil deutliche Vorteile bieten, beispielsweise die folgenden:

NFSv4-ACLs unterscheiden sich von Windows-ACLs auf Dateiebene (NTFS-ACLs), verfügen jedoch über ähnliche Funktionen. Wenn in Multiprotokoll-NAS-Umgebungen jedoch NFSv4.1-ACLs vorhanden sind und Sie einen Dualprotokoll-Zugriff (NFS und SMB auf denselben Datensätzen) verwenden, können Clients, die SMB2.0 und höher verwenden, ACLs nicht über die Windows-Sicherheitsregisterkarten anzeigen oder verwalten.

Zur Referenz werden die folgenden Begriffe definiert:

Wenn ein Client während eines SETATTR-Vorgangs eine NFSv4.1-ACL für eine Datei festlegt, legt Google Cloud NetApp Volumes diese ACL für das Objekt fest und ersetzt dabei alle vorhandenen ACLs. Wenn für eine Datei keine ACL vorhanden ist, werden die Modusberechtigungen für die Datei aus OWNER@, GROUP@ und EVERYONE@ berechnet. Wenn in der Datei bereits SUID/SGID/STICKY-Bits vorhanden sind, sind diese nicht betroffen.

Wenn ein Client im Verlauf eines GETATTR-Vorgangs eine NFSv4.1-ACL für eine Datei erhält, liest Google Cloud NetApp Volumes 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 Modusbits verfügt, wird aus den Modusbits eine ACL erstellt und an den Client zurückgegeben.

Der Zugriff wird verweigert, wenn in der ACL ein DENY ACE vorhanden ist; der Zugriff wird gewährt, wenn ein ALLOW ACE vorhanden ist. Der Zugriff wird jedoch auch verweigert, wenn keiner der ACEs in der ACL vorhanden ist.

Ein Sicherheitsdeskriptor besteht aus einer Sicherheits-ACL (SACL) und einer diskretionären ACL (DACL). Wenn NFSv4.1 mit CIFS/SMB interoperiert, wird die DACL eins zu eins mit NFSv4 und CIFS abgebildet. Die DACL besteht aus den ACEs ALLOW und DENY.

Wenn eine grundlegende chmod wird auf einer Datei oder einem Ordner mit festgelegten NFSv4.1-ACLs ausgeführt. Vorhandene Benutzer- und Gruppen-ACLs bleiben erhalten, die Standard-ACLs OWNER@, GROUP@ und EVERYONE@ werden jedoch 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 neues Unterverzeichnis in einem Verzeichnis mit einer ACL erstellt wird, erbt dieses Objekt alle ACEs in der ACL, die mit dem entsprechenden Tag versehen wurden. "Vererbungsflags" .

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

Dateien und Verzeichnisse erben ACEs von NFSv4-ACLs auf übergeordneten Verzeichnissen (möglicherweise mit entsprechenden Änderungen), solange die ACEs mit den richtigen Vererbungsflags 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 resultierende Verzeichnis davon ab, ob die Anforderung zur Dateierstellung 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.

NFSv4.1 ACLs-Berechtigungen verwenden eine Reihe von Groß- und Kleinbuchstaben (wie z. B. rxtncy ), um den Zugriff zu steuern. Weitere Informationen zu diesen Buchstabenwerten finden Sie unter "SO WIRD'S GEMACHT: Verwenden der NFSv4-ACL" .

"NFSv4-ACLs bieten die Möglichkeit, ACL-Vererbung anzubieten" . ACL-Vererbung bedeutet, dass Dateien oder Ordner, die unter Objekten mit festgelegten NFSv4.1-ACLs erstellt wurden, die ACLs basierend auf der Konfiguration des "ACL-Vererbungsflag" .

"Umask"wird verwendet, um die Berechtigungsstufe zu steuern, auf der Dateien und Ordner in einem Verzeichnis ohne Administratorinteraktion erstellt werden. Standardmäßig erlaubt Google Cloud NetApp Volumes umask, geerbte ACLs zu überschreiben, was gemäß "RFC 5661" .

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

Das obige Beispiel folgt den folgenden ACL-Formatrichtlinien:

Eine Art von A bedeutet „erlauben“. Die Vererbungsflags werden in diesem Fall nicht gesetzt, da der Auftraggeber keine Gruppe ist und keine Vererbung beinhaltet. Da es sich bei dem ACE nicht um einen AUDIT-Eintrag handelt, ist es auch nicht erforderlich, die Audit-Flags festzulegen. 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 vom Client und Server nicht aufgelöst werden kann), verhält sich die ACL möglicherweise nicht wie erwartet oder die ACL-Änderung kann nicht angewendet werden und es tritt ein Fehler auf.

Zu den Beispielfehlern gehören:

NFSv4.1-Berechtigungen können explizite DENY-Attribute für OWNER, GROUP und EVERYONE enthalten. Dies liegt daran, dass NFSv4.1-ACLs standardmäßig verweigert werden. Dies bedeutet, dass eine ACL verweigert wird, wenn sie nicht explizit durch einen ACE gewährt wird. Explizite DENY-Attribute überschreiben alle ACCESS ACEs, ob explizit oder nicht.

DENY ACEs werden mit einem Attribut-Tag von D .

Im folgenden Beispiel werden GROUP@ alle Lese- und Ausführungsberechtigungen gewährt, jedoch jeglicher Schreibzugriff verweigert.

DENY-ACEs sollten nach Möglichkeit vermieden werden, da sie verwirrend und kompliziert sein können; ALLOW-ACLs, die nicht explizit definiert sind, werden implizit abgelehnt. Wenn DENY ACEs festgelegt sind, kann Benutzern der Zugriff verweigert werden, obwohl sie damit rechnen, dass ihnen der Zugriff gewährt wird.

Der vorhergehende Satz von ACEs entspricht 755 Modusbits, was bedeutet:

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

NFSv4.1 nutzt die ID-Domänenzuordnungslogik als Sicherheitsebene, um zu überprüfen, ob ein Benutzer, der versucht, auf eine NFSv4.1-Einbindung zuzugreifen, tatsächlich derjenige ist, der er vorgibt zu sein. In diesen Fällen wird dem Benutzernamen und Gruppennamen vom NFSv4.1-Client eine Namenszeichenfolge angehängt und diese an die Google Cloud NetApp Volumes Instanz gesendet. Wenn die Kombination aus Benutzername/Gruppenname und ID-Zeichenfolge nicht übereinstimmt, wird der Benutzer und/oder die Gruppe auf den Standardbenutzer „nobody“ reduziert, der in der /etc/idmapd.conf Datei auf dem Client.

Diese ID-Zeichenfolge ist eine Voraussetzung für die ordnungsgemäße Einhaltung der Berechtigungen, insbesondere wenn NFSv4.1-ACLs und/oder Kerberos verwendet werden. Daher sind Abhängigkeiten von Nameservice-Servern wie LDAP-Servern erforderlich, um die Konsistenz zwischen Clients und Google Cloud NetApp Volumes für eine ordnungsgemäße Identitätsauflösung von Benutzer- und Gruppennamen sicherzustellen.

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

Wenn LDAP in Google Cloud NetApp Volumes aktiviert ist, automatisiert Google Cloud NetApp Volumes die Änderung der NFS-ID-Domäne zu der für die Suchdomäne in DNS konfigurierten Domäne. Clients müssen nicht geändert werden, es sei denn, sie verwenden andere DNS-Domänensuchnamen.

Wenn Google Cloud NetApp Volumes einen Benutzernamen oder Gruppennamen in lokalen Dateien oder LDAP auflösen kann, wird die Domänenzeichenfolge verwendet und nicht übereinstimmende Domänen-IDs werden auf „Niemand“ gequetscht. Wenn Google Cloud NetApp Volumes 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 ordnungsgemäß auf (dies ähnelt dem Verhalten von NFSv3).

Ohne die NFSv4.1-ID-Domäne des Clients so zu ändern, dass sie mit der vom Google Cloud NetApp Volumes Volume verwendeten übereinstimmt, sehen Sie das folgende Verhalten:

Im Folgenden sind die Ergebnisse des vorhergehenden Szenarios dargestellt:

Wenn die Client- und Server-ID-Domänen übereinstimmen, sieht die gleiche Dateiliste folgendermaßen aus:

Weitere Informationen zu diesem Problem und seiner Lösung finden Sie im Abschnitt „NFSv4.1 und der/die Niemand-Benutzer/Gruppe ."

Wenn Sie Kerberos mit NFS verwenden möchten, müssen Sie bei Google Cloud NetApp Volumes über Folgendes verfügen:

Eines der häufigsten Probleme bei einer NFSv4.1-Konfiguration ist, wenn eine Datei oder ein Ordner in einer Liste mit ls als Eigentum der user:group Kombination aus nobody:nobody .

Beispiel:

Und die numerische ID ist 99 .

In manchen Fällen zeigt die Datei zwar den richtigen Besitzer an, nobody als Gruppe.

Wer ist niemand?

Der nobody Benutzer in NFSv4.1 unterscheidet sich von nfsnobody Benutzer. Sie können sehen, wie ein NFS-Client jeden Benutzer sieht, indem Sie den id Befehl:

Mit NFSv4.1 wird die nobody Benutzer ist der Standardbenutzer, der vom idmapd.conf Datei und kann als jeder beliebige Benutzer definiert werden.

Warum passiert das?

Da Sicherheit durch Namenszeichenfolgenzuordnung ein zentraler Grundsatz von NFSv4.1-Vorgängen ist, besteht das Standardverhalten bei einer nicht korrekten Übereinstimmung einer Namenszeichenfolge darin, den Benutzer auf einen Namen zu beschränken, der normalerweise keinen Zugriff auf Dateien und Ordner hat, die Benutzern 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 Groß- und Kleinschreibung eine Rolle spielen.

Wenn beispielsweise user1@CVSDEMO.LOCAL (uid 1234, gid 1234) auf einen Export zugreift, muss Google Cloud NetApp Volumes in der Lage sein, user1@CVSDEMO.LOCAL (uid 1234, gid 1234) zu finden. Wenn der Benutzer in Google Cloud NetApp Volumes USER1@CVSDEMO.LOCAL ist, stimmt dies nicht überein (USER1 in Großbuchstaben gegenüber user1 in Kleinbuchstaben). In vielen Fällen können Sie in der Nachrichtendatei auf dem Client Folgendes sehen:

Client und Server müssen sich darüber einig sein, dass ein Benutzer tatsächlich der ist, der 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 sehen nobody In Benutzer- und Gruppenlisten von Clients liegt das Problem in der Übersetzung der Domänen-ID des Benutzer- oder Gruppennamens zwischen Google Cloud NetApp Volumes und dem NFS-Client. Um dieses Szenario zu vermeiden, verwenden Sie LDAP, um Benutzer- und Gruppeninformationen zwischen Clients und Google Cloud NetApp Volumes aufzulösen.

Wenn Sie NFSv4.1 verwenden, findet während NFS-Vorgängen eine Name-String-Zuordnung statt, wie zuvor beschrieben.

Neben der Verwendung /var/log/messages Um ein Problem mit NFSv4-IDs zu finden, können Sie die "nfsidmap -l" auf dem NFS-Client, um anzuzeigen, welche Benutzernamen der NFSv4-Domäne ordnungsgemäß zugeordnet wurden.

Dies ist beispielsweise die Ausgabe des Befehls, nachdem ein Benutzer, der vom Client und Google Cloud NetApp Volumes gefunden werden kann, auf ein NFSv4.x-Mount zugreift:

Wenn ein Benutzer nicht richtig in die NFSv4.1-ID-Domäne abgebildet wird (in diesem Fall netapp-user ) versucht, auf denselben Mount zuzugreifen und eine Datei berührt, werden sie zugewiesen nobody:nobody , wie erwartet.

Der nfsidmap -l Die Ausgabe zeigt den Benutzer pcuser im Display, aber nicht netapp-user ; dies ist der anonyme Benutzer in unserer Exportrichtlinienregel(65534 ).