Verwenden von NFSv4.x-Zugriffssteuerungslisten in Azure NetApp Files
Das NFSv4.x-Protokoll kann die Zugriffssteuerung in Form von Zugriffssteuerungslisten (Access Control Lists, ACLs) bereitstellen, die konzeptuell mit den Zugriffssteuerungslisten vergleichbar sind, die in SMB (Server Message Block) über Windows NTFS-Berechtigungen verwendet werden. Eine NFSv4.x-ACL besteht aus einzelnen Zugriffssteuerungseinträgen (Access Control Entries, ACEs), die jeweils eine Zugriffssteuerungsanweisung für den Server bereitstellen.
Jede NFSv4.x-ACL wird im Format type:flags:principal:permissions erstellt.
- Type: Der Typ der ACL, die definiert wird. Zu den gültigen Optionen zählen „Access“ (A, Zugriff), „Deny“ (D, Verweigern), „Audit“ (U, Überwachung) und „Alarm“ (L). Azure NetApp Files unterstützt die ACL-Typen „Access“, „Deny“ und „Audit“. ACLs vom Typ „Audit“ können zwar festgelegt werden, erzeugen derzeit jedoch keine Überwachungsprotokolle.
- Flags: Fügt zusätzlichen Kontext für eine ACL hinzu. Es gibt drei Arten von Zugriffssteuerungseintrags-Flags: Gruppen-, Vererbungs- und Verwaltungsflags. Weitere Informationen zu Flags finden Sie unter NFSv4.x-ACE-Flags.
- Principal: Definiert den Benutzer oder die Gruppe, der bzw. die der ACL zugewiesen wird. Ein Prinzipal für eine NFSv4.x-ACL wird im Format name@ID-DOMAIN-STRING.COM angegeben. Ausführlichere Informationen zu Prinzipalen finden Sie unter NFSv4.x-Benutzer- und Gruppenprinzipale.
- Permissions: Hier wird die Zugriffsebene für den Prinzipal definiert. Jede Berechtigung wird mit einem einzelnen Buchstaben festgelegt (z. B. „r“ für Lesezugriff, „w“ für Schreibzugriff usw.). Für Vollzugriff werden alle verfügbaren Berechtigungsbuchstaben angegeben. Weitere Informationen finden Sie unter NFSv4.x-Berechtigungen.
A:g:group1@contoso.com:rwatTnNcCy ist ein Beispiel für eine gültige ACL im Format type:flags:principal:permissions. Die Beispiel-ACL gewährt der Gruppe group1 in der ID-Domäne „contoso.com“ Vollzugriff.
NFSv4.x-ACE-Flags
Mit einem Zugriffssteuerungseintrags-Flag können weitere Informationen zu einem Zugriffssteuerungseintrag in einer ACL bereitgestellt werden. Wenn einer ACL z. B. ein Zugriffssteuerungseintrag für eine Gruppe hinzugefügt wird, muss ein Gruppenflag verwendet werden, um anzugeben, dass es sich beim Prinzipal um eine Gruppe handelt und nicht um einen Benutzer. In Linux-Umgebungen ist es möglich, identische Benutzer- und Gruppennamen zu verwenden. Das Flag stellt daher sicher, dass ein Zugriffssteuerungseintrag berücksichtigt wird und dass der NFS-Server weiß, welche Art von Prinzipal definiert wird.
Andere Flags können zum Steuern von Zugriffssteuerungseinträgen verwendet werden, z. B. die Vererbungs- und Verwaltungsflags.
Zugriffs- und Verweigerungsflags
Die Flags für Zugriff (Access, A) und Verweigern (Deny, D) werden verwendet, um Zugriffssteuerungseinträge zu steuern, die die Sicherheit betreffen. Ein Zugriffssteuerungseintrag mit einem Zugriffsflag steuert die Ebene der Zugriffsberechtigungen für eine Datei oder einen Ordner für einen Prinzipal. Ein Zugriffssteuerungseintrag mit einem Verweigerungsflag verbietet einem Prinzipal explizit den Zugriff auf eine Datei oder einen Ordner, auch wenn ein Zugriffssteuerungseintrag mit einem Zugriffsflag festgelegt ist, der diesem Prinzipal den Zugriff auf das Objekt erlauben würde. Zugriffssteuerungseinträge mit einem Verweigerungsflag setzen Einträge mit einem Zugriffsflag immer außer Kraft. Im Allgemeinen sollte die Verwendung von Zugriffssteuerungseinträgen mit einem Verweigerungsflag vermieden werden, da NFSv4.x-ACLs einem Modell mit dem Standardwert „Verweigern“ folgen, was bedeutet, dass implizit der Wert „Verweigern“ angewendet wird, wenn eine ACL nicht hinzugefügt wird. Zugriffssteuerungseinträge mit einem Verweigerungsflag können zu unnötigen Komplikationen bei der ACL-Verwaltung führen.
Vererbungsflags
Vererbungsflags steuern, wie sich ACLs bei Dateien verhalten, die unter einem übergeordneten Verzeichnis mit festgelegtem Vererbungsflag erstellt wurden. Wenn ein Vererbungsflag festgelegt ist, erben Dateien und/oder Verzeichnisse die ACLs vom übergeordneten Ordner. Vererbungsflags können nur auf Verzeichnisse angewendet werden. Wenn ein Unterverzeichnis erstellt wird, erbt dieses folglich das Flag. Dateien, die unter einem übergeordneten Verzeichnis mit einem Vererbungsflag erstellt werden, erben ACLs, aber nicht die Vererbungsflags.
In der folgenden Tabelle werden die verfügbaren Vererbungsflags und deren Verhalten beschrieben.
| Vererbungsflag | Verhalten |
|---|---|
| d | - Verzeichnisse unter dem übergeordneten Verzeichnis erben die ACL. - Das Vererbungsflag wird ebenfalls vererbt. |
| f | - Dateien unter dem übergeordneten Verzeichnis erben die ACL. - Dateien legen kein Vererbungsflag fest. |
| i | Inherit-only (nur erben). Die ACL gilt nicht für das aktuelle Verzeichnis, muss jedoch die Vererbung auf Objekte unterhalb des Verzeichnisses anwenden. |
| n | - Keine Weitergabe der Vererbung Nachdem die ACL geerbt wurde, werden die Vererbungsflags für die Objekte unterhalb des übergeordneten Elements gelöscht. |
Beispiele für NFSv4.x-ACLs
Im folgenden Beispiel werden drei verschiedene Zugriffssteuerungseinträge mit unterschiedlichen Vererbungsflags verwendet:
- Nur Vererbung an Verzeichnisse (di)
- Nur Vererbung an Dateien (fi)
- Vererbung an Dateien und Verzeichnisse (fdi)
# nfs4_getfacl acl-dir
# file: acl-dir/
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdi:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
User1 verfügt über eine ACL, bei der nur die Vererbung an Verzeichnisse festgelegt ist. Bei einem Unterverzeichnis, das unter dem übergeordneten Element erstellt wird, wird die ACL vererbt, bei einer darunter erstellten Datei jedoch nicht.
# nfs4_getfacl acl-dir/inherit-dir
# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
# nfs4_getfacl acl-dir/inherit-file
# file: acl-dir/inherit-file
<< ACL missing
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy
User2 verfügt über eine ACL, bei der die Vererbung an Dateien und Verzeichnisse festgelegt ist. Daher erben sowohl Dateien als auch Verzeichnisse unter einem Verzeichnis mit diesem Zugriffssteuerungseintrag die ACL, Dateien erben das Flag jedoch nicht.
# nfs4_getfacl acl-dir/inherit-dir
# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
# nfs4_getfacl acl-dir/inherit-file
# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy << no flag
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy
User3 verfügt über ein Flag für die Vererbung an Dateien. Daher erben nur Dateien unter dem Verzeichnis mit diesem Zugriffssteuerungseintrag die ACL, sie erben jedoch nicht das Flag, da dieses nur auf Zugriffssteuerungseinträge für Verzeichnisse angewendet werden kann.
# nfs4_getfacl acl-dir/inherit-dir
# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
# nfs4_getfacl acl-dir/inherit-file
# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy << no flag
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy
Wenn das Flag „n“ (keine Weitergabe) für eine ACL festgelegt ist, werden für Verzeichnisse, die nachfolgend unter dem übergeordneten Element erstellt werden, die Flags gelöscht. Im folgenden Beispiel ist für user2 das Flag n festgelegt. Daher löscht das Unterverzeichnis die Vererbungsflags für diesen Prinzipal, und Objekte, die unter diesem Unterverzeichnis erstellt werden, erben nicht den Zugriffssteuerungseintrag von user2.
# nfs4_getfacl /mnt/acl-dir
# file: /mnt/acl-dir
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdn:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
# nfs4_getfacl inherit-dir/
# file: inherit-dir/
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A::user2@CONTOSO.COM:rwaDxtTnNcCy << flag cleared
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
# mkdir subdir
# nfs4_getfacl subdir
# file: subdir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
<< ACL not inherited
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
Vererbungsflags vereinfachen die Verwaltung Ihrer NFSv4.x-ACLs, da Sie nicht jedes Mal, wenn Sie eine ACL benötigen, explizit eine ACL festlegen müssen.
Verwaltungsflags
Verwaltungsflags in NFSv4.x-ACLs sind spezielle Flags, die nur bei den ACL-Typen „Audit“ und „Alarm“ verwendet werden. Diese Flags definieren erfolgreiche (S) oder fehlgeschlagene (F) Zugriffsversuche für Aktionen, die ausgeführt werden sollen.
Azure NetApp Files unterstützt das Festlegen von Verwaltungsflags für Zugriffssteuerungseinträge vom Typ „Audit“, die Zugriffssteuerungseinträge funktionieren jedoch nicht. Zudem werden Zugriffssteuerungseinträge vom Typ „Alarm“ in Azure NetApp Files nicht unterstützt.
NFSv4.x-Benutzer- und Gruppenprinzipale
Bei NFSv4.x-ACLs definieren Benutzer- und Gruppenprinzipale die spezifischen Objekte, auf die ein Zugriffssteuerungseintrag angewendet werden soll. Prinzipale werden in der Regel im Format name@ID-DOMAIN-STRING.COM angegeben. Beim Teil „name“ eines Prinzipals kann es sich um einen Benutzer oder eine Gruppe handeln, dieser Benutzer- bzw. Gruppenname muss jedoch in Azure NetApp Files über die LDAP-Serververbindung aufgelöst werden können, wenn die NFSv4.x-ID-Domäne angegeben wird. Wenn „name@domain“ nicht von Azure NetApp Files aufgelöst werden kann, tritt beim ACL-Vorgang ein Fehler vom Typ „ungültiges Argument“ auf.
# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument
Sie können in Azure NetApp Files überprüfen, ob ein Name mithilfe der Liste der LDAP-Gruppen-IDs aufgelöst werden kann. Navigieren Sie zu Support + Fehlerbehebung und dann zur Liste der LDAP-Gruppen-IDs.
Zugriff von lokalen Benutzern und Gruppen über NFSv4.x-ACLs
Lokale Benutzer und Gruppen können auch dann für eine NFSv4.x-ACL verwendet werden, wenn nur die numerische ID in der ACL angegeben ist. Bei Benutzernamen oder numerische IDs mit einer angegebenen Domänen-ID tritt ein Fehler auf.
Beispiel:
# nfs4_setfacl -a A:fdg:3003:rwaxtTnNcCy NFSACL
# nfs4_getfacl NFSACL/
A:fdg:3003:rwaxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rwaDxtTnNcy
A::EVERYONE@:rwaDxtTnNcy
# nfs4_setfacl -a A:fdg:3003@CONTOSO.COM:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument
# nfs4_setfacl -a A:fdg:users:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument
Wenn eine ACL für lokale Benutzer oder Gruppen festgelegt wird, erhalten alle Benutzer oder Gruppen, die der numerischen ID in der ACL entsprechen, Zugriff auf das Objekt. Bei ACLs für lokale Gruppen übergibt ein Benutzer seine Gruppenmitgliedschaften an Azure NetApp Files. Wenn die numerische ID der Gruppe mit Zugriff auf die Datei über die Anforderung des Benutzers für den Azure NetApp Files-NFS-Server angezeigt wird, ist der Zugriff gemäß der ACL zulässig.
Die vom Client an den Server übergebenen Anmeldeinformationen können wie unten dargestellt über eine Paketerfassung angezeigt werden.
Einschränkungen:
- Die Verwendung von lokalen Benutzern und Gruppen für ACLs erfordert, dass jeder Client, der auf die Dateien/Ordner zugreift, über übereinstimmende Benutzer- und Gruppen-IDs verfügt.
- Wenn Sie eine numerische ID für eine ACL verwenden, vertraut Azure NetApp Files implizit darauf, dass die eingehende Anforderung gültig ist und dass der Benutzer, der den Zugriff anfordert, authentisch und Mitglied der angegebenen Gruppen ist. Eine numerische Benutzer- oder Gruppen-ID kann gefälscht werden, wenn böswillige Akteure die numerische ID kennen, und verwendet werden, um über einen Client auf das Netzwerk zuzugreifen und Benutzer und Gruppen lokal zu erstellen.
- Wenn ein Benutzer Mitglied von mehr als 16 Gruppen ist, wird jeder Gruppe nach der 16. Gruppe (in alphanumerischer Reihenfolge) der Zugriff auf die Datei oder den Ordner verweigert, sofern nicht LDAP und die erweiterte Gruppenunterstützung verwendet werden.
- Aus Gründen der besseren Verwaltbarkeit und aus Sicherheitsgründen wird empfohlen, bei der Verwendung von NFSv4.x-ACLs LDAP und Zeichenfolgen im Format „vollständiger Name@Domänenname“ zu verwenden. Ein zentral verwaltetes Benutzer- und Gruppenrepository ist einfacher zu verwalten und erschwert Spoofing, sodass die Wahrscheinlichkeit von unerwünschten Benutzerzugriffen reduziert wird.
NFSv4.x-ID-Domäne
Die ID-Domäne ist eine wichtige Komponente des Prinzipals. Eine ID-Domäne muss sowohl auf dem Client als auch in Azure NetApp Files übereinstimmen, damit Benutzer- und Gruppennamen (insbesondere Stammnamen) ordnungsgemäß im Datei-/Ordnerbesitz angezeigt werden.
Azure NetApp Files legt die NFSv4.x-ID-Domäne standardmäßig auf die DNS-Domäneneinstellungen für das Volume fest. NFS-Clients verwenden ebenfalls standardmäßig die DNS-Domäne für die NFSv4.x-ID-Domäne. Wenn sich die DNS-Domäne des Clients von der DNS-Domäne von Azure NetApp Files unterscheidet, tritt ein Konflikt auf. Wenn Sie Dateiberechtigungen mit Befehlen wie lsauflisten, werden Benutzer/Gruppen als „nobody“ angezeigt.
Wenn ein Domänenkonflikt zwischen dem NFS-Client und Azure NetApp Files auftritt, überprüfen Sie die Clientprotokolle auf Fehler der folgenden Art:
August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'
Die ID-Domäne des NFS-Clients kann mithilfe der Einstellung „Domäne“ der Datei „/etc/idmapd.conf“ außer Kraft gesetzt werden. Beispiel: Domain = CONTOSO.COM
Azure NetApp Files ermöglicht Ihnen auch das Ändern der NFSv4.1-ID-Domäne. Weitere Informationen finden Sie unter How-to: NFSv4.1 ID Domain Configuration for Azure NetApp Files (NFSv4.1-ID-Domänenkonfiguration für Azure NetApp Files).
NFSv4.x-Berechtigungen
NFSv4.x-Berechtigungen dienen zum Steuern der Zugriffsebene, die bestimmten Benutzer- oder Gruppenprinzipalen für eine Datei oder einen Ordner zugewiesen wird. Berechtigungen in NFSv3 lassen nur die Ebenen „Lesen“, „Schreiben“ und „Ausführen“ (Read/Write/Execute, rwx) der Zugriffsdefinition zu. NFSv4.x bietet jedoch als Verbesserung gegenüber NFSv3-Modusbits eine Reihe weiterer granularer Zugriffssteuerungen.
Es gibt 13 Berechtigungen, die für Benutzer festgelegt werden können, und 14 Berechtigungen für Gruppen.
| Buchstabe für die Berechtigung | Berechtigung wurde gewährt |
|---|---|
| r | Daten lesen/Dateien und Ordner auflisten |
| a | Daten schreiben/Dateien und Ordner erstellen |
| a | Daten anfügen/Unterverzeichnisse erstellen |
| x | Dateien ausführen/Verzeichnisse durchsuchen |
| d | Löschen von Dateien/Verzeichnissen |
| D | Unterverzeichnisse löschen (nur Verzeichnisse) |
| t | Attribute lesen (GETATTR) |
| T | Attribute schreiben (SETATTR/chmod) |
| n | Benannte Attribute lesen |
| N | Benannte Attribute schreiben |
| c | ACLs lesen |
| C | ACLs schreiben |
| o | Besitzer schreiben (chown) |
| Y | Synchrone E/A-Vorgänge |
Wenn Zugriffsberechtigungen festgelegt sind, gelten diese zugewiesenen Rechte für einen Benutzer- oder Gruppenprinzipal.
Beispiele für NFSv4.x-Berechtigungen
Die folgenden Beispiele zeigen, wie unterschiedliche Berechtigungen in verschiedenen Konfigurationsszenarien funktionieren.
Benutzer mit der Berechtigung „r“ (Lesezugriff)
Mit schreibgeschütztem Zugriff kann ein Benutzer Attribute und Daten lesen, jeglicher Schreibzugriff (Daten, Attribute, Besitzer) wird jedoch verweigert.
A::user1@CONTOSO.COM:r
sh-4.2$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Jul 12 12:41 .
drwxr-xr-x 3 root root 4096 Jul 12 12:09 ..
-rw-r--r-- 1 root root 0 Jul 12 12:41 file
drwxr-xr-x 2 root root 4096 Jul 12 12:31 subdir
sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ chown user1 file
chown: changing ownership of ‘file’: Operation not permitted
sh-4.2$ nfs4_setfacl -e /mnt/acl-dir/inherit-dir
Failed setxattr operation: Permission denied
sh-4.2$ rm file
rm: remove write-protected regular empty file ‘file’? y
rm: can't remove ‘file’: Permission denied
sh-4.2$ cat file
Test text
Benutzer mit den Berechtigungen „r“ (Lesezugriff) und „T“ (Attribute schreiben)
In diesem Beispiel können Berechtigungen für die Datei aufgrund der Berechtigung „Attribute schreiben“ (T) geändert werden, es können aber keine Dateien erstellt werden, da nur Lesezugriff zulässig ist. Diese Konfiguration veranschaulicht die granulare Steuerung, die NFSv4.x-ACLs ermöglichen.
A::user1@CONTOSO.COM:rT
sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ ls -la
total 60
drwxr-xr-x 3 root root 4096 Jul 12 16:23 .
drwxr-xr-x 19 root root 49152 Jul 11 09:56 ..
-rw-r--r-- 1 root root 10 Jul 12 16:22 file
drwxr-xr-x 3 root root 4096 Jul 12 12:41 inherit-dir
-rw-r--r-- 1 user1 group1 0 Jul 12 16:23 user1-file
sh-4.2$ chmod 777 user1-file
sh-4.2$ ls -la
total 60
drwxr-xr-x 3 root root 4096 Jul 12 16:41 .
drwxr-xr-x 19 root root 49152 Jul 11 09:56 ..
drwxr-xr-x 3 root root 4096 Jul 12 12:41 inherit-dir
-rwxrwxrwx 1 user1 group1 0 Jul 12 16:23 user1-file
sh-4.2$ rm user1-file
rm: can't remove ‘user1-file’: Permission denied
Übersetzen von Modusbits in NFSv4.x-ACL-Berechtigungen
Wenn „chmod“ für ein Objekt ausgeführt wird, dem NFSv4.x-ACLs zugewiesen sind, werden mehrere System-ACLs mit neuen Berechtigungen aktualisiert. Wenn die Berechtigungen beispielsweise auf 755 festgelegt sind, werden die System-ACL-Dateien aktualisiert. Die folgende Tabelle zeigt, wie die einzelnen numerischen Werte in einem Modusbit in NFSv4-ACL-Berechtigungen übersetzt werden.
Eine Tabelle mit einer Beschreibung aller Berechtigungen finden Sie unter NFSv4.x-Berechtigungen.
| Numerischer Modusbitwert | Entsprechende NFSv4.x-Berechtigungen |
|---|---|
| 1 – Ausführen (Execute, x) | Ausführen, Attribute lesen, ACLs lesen, E/A synchronisieren (xtcy) |
| 2 – Schreiben (w) | Schreiben, Daten anfügen, Attribute lesen, Attribute schreiben, benannte Attribute schreiben, ACLs lesen, E/A synchronisieren (watTNcy) |
| 3 – Schreiben/Ausführen (wx) | Schreiben, Daten anfügen, ausführen, Attribute lesen, Attribute schreiben, benannte Attribute schreiben, ACLs lesen, E/A synchronisieren (waxtTNcy) |
| 4 – Lesen (r) | Lesen, Attribute lesen, benannte Attribute lesen, ACLs lesen, E/A synchronisieren (rtncy) |
| 5 – Lesen/Ausführen (rx) | Lesen, ausführen, Attribute lesen, benannte Attribute lesen, ACLs lesen, E/A synchronisieren (rxtncy) |
| 6 – Lesen/Schreiben (rw) | Lesen, schreiben, Daten anfügen, Attribute lesen, Attribute schreiben, benannte Attribute lesen, benannte Attribute schreiben, ACLs lesen, E/A synchronisieren (rwatTnNcy) |
| 7 – Lesen/Schreiben/Ausführen (rwx) | Vollzugriff/Alle Berechtigungen |
Verwendung von NFSv4.x-ACLs mit Azure NetApp Files
Azure NetApp Files unterstützt NFSv4.x-ACLs nativ, wenn auf einem Volume NFSv4.1 für den Zugriff aktiviert ist. Es gibt keine Volumeeinstellungen, die für die ACL-Unterstützung aktiviert werden können. Damit NFSv4.1-ACLs optimal funktionieren, ist jedoch ein LDAP-Server mit UNIX-Benutzern und -Gruppen erforderlich, um sicherzustellen, dass Azure NetApp Files die für die ACLs festgelegten Prinzipale sicher auflösen kann. Lokale Benutzer können mit NFSv4.x-ACLs verwendet werden, bieten jedoch nicht die gleiche Sicherheit wie ACLs, die mit einem LDAP-Server verwendet werden.
Hinsichtlich der ACL-Funktionalität in Azure NetApp Files müssen verschiedene Aspekte berücksichtigt werden.
ACL-Vererbung
In Azure NetApp Files können ACL-Vererbungsflags verwendet werden, um die ACL-Verwaltung mit NFSv4.x-ACLs zu vereinfachen. Wenn ein Vererbungsflag festgelegt ist, können ACLs für ein übergeordnetes Verzeichnis ohne weitere Interaktion an Unterverzeichnisse und Dateien weitergegeben werden. Azure NetApp Files implementiert das standardmäßige ACL-Vererbungsverhalten gemäß RFC-7530.
AcEs verweigern
Zugriffssteuerungseinträge mit einem Verweigerungsflag werden in Azure NetApp Files verwendet, um Benutzern oder Gruppen den Zugriff auf eine Datei oder einen Ordner explizit zu verweigern. Es kann eine Teilmenge von Berechtigungen definiert werden, um Zugriffssteuerungseinträge mit einem Verweigerungsflag präziser zu steuern. Diese Berechtigungen funktionieren entsprechend den in RFC-7530 genannten Standardmethoden.
Beibehaltung von ACLs
Wenn „chmod“ für eine Datei oder einen Ordner in Azure NetApp Files ausgeführt wird, werden mit Ausnahme der System-Zugriffssteuerungseinträge (OWNER@, GROUP@, EVERYONE@) alle vorhandenen Zugriffssteuerungseinträge in der ACL beibehalten. Diese Berechtigungen in Zugriffssteuerungseinträgen werden entsprechend den numerischen Modusbits gemäß der Definition des Befehls „chmod“ geändert. Nur Zugriffssteuerungseinträge, die über den Befehl nfs4_setfacl manuell geändert oder entfernt werden, können geändert werden.
Verhalten von NFSv4.x-ACLs in Dual-Protokoll-Umgebungen
Der Begriff „Dual-Protokoll“ (zwei Protokolle) bezieht sich auf die Verwendung von SMB und NFS auf demselben Azure NetApp Files-Volume. Dual-Protokoll-Zugriffssteuerungen werden durch den vom Volume verwendeten Sicherheitsstil bestimmt. Die Benutzernamenzuordnung stellt jedoch sicher, dass Windows-Benutzer und UNIX-Benutzer, die einander erfolgreich zugeordnet werden, über dieselben Zugriffsberechtigungen für Daten verfügen.
Wenn NFSv4.x-ACLs auf Volumes mit dem UNIX-Sicherheitsstil verwendet werden, kann bei der Verwendung von Dual-Protokoll-Volumes und beim Zugriff auf Daten über SMB-Clients das folgende Verhalten auftreten.
- Windows-Benutzernamen müssen Unix-Benutzernamen korrekt zugeordnet werden, um die richtige Zugriffssteuerungsauflösung zu erhalten.
- Wenn bei Volumes mit dem UNIX-Sicherheitsstil (auf denen NFSv4.x-ACLs angewendet werden) kein gültiger UNIX-Benutzer auf dem LDAP-Server vorhanden ist, dem ein Windows-Benutzer zugeordnet werden kann, wird ein UNIX-Standardbenutzer namens
pcuser(mit der UID 65534) für die Zuordnung verwendet. - Dateien, die mit Windows-Benutzern ohne gültige UNIX-Benutzerzuordnung geschrieben werden, werden als Dateien im Besitz der numerischen ID 65534 angezeigt, was den Benutzernamen „nfsnobody“ oder „nobody“ in Linux-Clients von NFS-Bereitstellungen entspricht. Dies unterscheidet sich von der numerischen ID 99, die bei Problemen mit NFSv4.x-ID-Domänen in der Regel ausgegeben wird. Verwenden Sie den Befehl
ls -lan, um die verwendete numerische ID zu überprüfen. - Dateien mit falschen Besitzern liefern für UNIX-Modusbits oder NFSv4.x-ACLs nicht die erwarteten Ergebnisse.
- NFSv4.x-ACLs werden über NFS-Clients verwaltet. SMB-Clients können NFSv4.x-ACLs weder anzeigen noch verwalten.
Auswirkung der Verwendung von „unmask“ mit NFSv4.x-ACLs
NFSv4-ACLs bieten die Möglichkeit, ACL-Vererbung anzubieten. ACL-Vererbung bedeutet, dass Dateien oder Ordner, die unter Objekten mit NFSv4-ACLs erstellt werden, die ACLs basierend auf der Konfiguration des ACL-Vererbungsflags erben können.
„Umask“ wird verwendet, um die Berechtigungsebene zu steuern, mit der Dateien und Ordner in einem Verzeichnis erstellt werden. Standardmäßig ermöglicht Azure NetApp Files die Außerkraftsetzung von geerbten ACLs mit dem Befehl „umask“, was das erwartete Verhalten gemäß RFC-7530- ist.
Weitere Informationen finden Sie unter umask.
Verhalten von „chmod“ und “chown“ bei NFSv4.x-ACLs
In Azure NetApp Files können Sie Befehle zum Ändern des Besitzes (chown) und Ändern des Modusbits (chmod) verwenden, um Datei- und Verzeichnisberechtigungen für NFSv3 und NFSv4.x zu verwalten.
Bei der Verwendung von NFSv4.x-ACLs ist die Ausführung von chmod-Befehlen aufgrund der präziseren Steuerungen, die auf Dateien und Ordner angewendet werden, seltener erforderlich. Der Befehl „chown“ ist weiterhin notwendig, da NFSv4.x-ACLs keinen Besitzer zuweisen.
Wenn „chmod“ in Azure NetApp Files für Dateien und Ordner mit angewendeten NFSv4.x-ACLs ausgeführt wird, werden Modusbits für das Objekt geändert. Darüber hinaus werden mehrere System-Zugriffssteuerungseinträge geändert, um diese Modusbits widerzuspiegeln. Wenn die System-Zugriffssteuerungseinträge entfernt werden, werden Modusbits gelöscht. Beispiele und eine ausführlichere Beschreibung finden Sie weiter unten im Abschnitt zu System-Zugriffssteuerungseinträgen.
Wenn „chown“ in Azure NetApp Files ausgeführt wird, kann der zugewiesene Besitzer geändert werden. Der Dateibesitz ist bei der Verwendung von NFSv4.x-ACLs weniger wichtig als bei der Verwendung von Modusbits, da ACLs eine präzisere Steuerung von Berechtigungen ermöglichen als die grundlegenden Konzepte „Besitzer“, „Gruppe“ oder „Jeder“ (owner/group/everyone). Der Befehl „chown“ kann in Azure NetApp Files nur als Stammbenutzer ausgeführt werden (entweder als „root“ oder mit „sudo“), da die Exportsteuerelemente so konfiguriert sind, dass nur der Stammbenutzer Besitzeränderungen vornehmen kann. Da dies durch eine standardmäßige Exportrichtlinienregel in Azure NetApp Files gesteuert wird, werden NFSv4.x-ACL-Einträge, die Besitzänderungen zulassen, nicht angewendet.
# su user1
# chown user1 testdir
chown: changing ownership of ‘testdir’: Operation not permitted
# sudo chown user1 testdir
# ls -la | grep testdir
-rw-r--r-- 1 user1 root 0 Jul 12 16:23 testdir
Die Exportrichtlinienregel für das Volume kann geändert werden, um dieses Verhalten zu ändern. Ändern Sie im Menü Richtlinie exportieren für das Volume die Einstellung Chown-Modus in „Nicht eingeschränkt“.
Nach der Änderung kann der Besitz von anderen Benutzern als dem Stammbenutzer geändert werden, sofern diese über entsprechende Zugriffsrechte verfügen. Dies erfordert die NFSv4.x-ACL-Berechtigung „Besitz übernehmen“ (angegeben durch den Buchstaben „o“). Der Besitz kann auch geändert werden, wenn der Benutzer, der den Besitz ändert, gegenwärtig der Besitzer der Datei oder des Ordners ist.
A::user1@contoso.com:rwatTnNcCy << no ownership flag (o)
user1@ubuntu:/mnt/testdir$ chown user1 newfile3
chown: changing ownership of 'newfile3': Permission denied
A::user1@contoso.com:rwatTnNcCoy << with ownership flag (o)
user1@ubuntu:/mnt/testdir$ chown user1 newfile3
user1@ubuntu:/mnt/testdir$ ls -la
total 8
drwxrwxrwx 2 user2 root 4096 Jul 14 16:31 .
drwxrwxrwx 5 root root 4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1 root 0 Jul 14 15:45 newfile
-rw-r--r-- 1 root root 0 Jul 14 15:52 newfile2
-rw-r--r-- 1 user1 4294967294 0 Jul 14 16:31 newfile3
System-Zugriffssteuerungseinträge
Für jede ACL gibt es eine Reihe von System-Zugriffssteuerungseinträgen: OWNER@, GROUP@, EVERYONE@. Beispiel:
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy
Diese Zugriffssteuerungseinträge entsprechen den klassischen Modusbitberechtigungen in NFSv3 und sind diesen Berechtigungen direkt zugeordnet. Wenn ein chmod-Befehl für ein Objekt ausgeführt wird, ändern sich diese System-ACLs, um die Berechtigungen widerzuspiegeln.
# nfs4_getfacl user1-file
# file: user1-file
A::user1@CONTOSO.COM:rT
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy
# chmod 755 user1-file
# nfs4_getfacl user1-file
# file: user1-file
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rxtncy
Wenn diese System-Zugriffssteuerungseinträge entfernt werden, ändert sich die Berechtigungsansicht, sodass die normalen Modusbits (rwx) als Gedankenstriche angezeigt werden.
# nfs4_setfacl -x A::OWNER@:rwaxtTnNcCy user1-file
# nfs4_setfacl -x A:g:GROUP@:rxtncy user1-file
# nfs4_setfacl -x A::EVERYONE@:rxtncy user1-file
# ls -la | grep user1-file
---------- 1 user1 group1 0 Jul 12 16:23 user1-file
Das Entfernen von System-Zugriffssteuerungseinträgen ist eine Möglichkeit, Dateien und Ordner zusätzlich zu schützen, da nur die Benutzer- und Gruppenprinzipale in der ACL (und der Stammbenutzer) auf das Objekt zugreifen können. Das Entfernen von System-Zugriffssteuerungseinträgen kann zur Funktionsunfähigkeit von Anwendungen führen, die Modusbitansichten erfordern.
Verhalten des Stammbenutzers (root) bei NFSv4.x-ACLs
Der Stammzugriff mit NFSv4.x-ACLs kann nur eingeschränkt werden, wenn Root-Squashing aktiviert ist. Beim Root-Squashing wird eine Exportrichtlinienregel konfiguriert, in der der Stamm (root) einem anonymen Benutzer zugeordnet wird, um den Zugriff zu beschränken. Der Stammzugriff kann über das Menü Exportrichtlinie eines Volumes konfiguriert werden, indem die Richtlinienregel Stammzugriff deaktiviert wird.
Navigieren Sie zum Konfigurieren von Root-Squashing zum Menü Exportrichtlinie des Volumes, und ändern Sie die Einstellung der Option „Stammzugriff“ für die Richtlinienregel in „Deaktiviert“.
Durch die Deaktivierung des Stammzugriffs wird ein Squash für den Benutzer nfsnobody:65534 ausgeführt. Mit dem Stammzugriff kann der Besitz dann nicht geändert werden.
root@ubuntu:/mnt/testdir# touch newfile3
root@ubuntu:/mnt/testdir# ls -la
total 8
drwxrwxrwx 2 user2 root 4096 Jul 14 16:31 .
drwxrwxrwx 5 root root 4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1 root 0 Jul 14 15:45 newfile
-rw-r--r-- 1 root root 0 Jul 14 15:52 newfile2
-rw-r--r-- 1 nobody 4294967294 0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# ls -lan
total 8
drwxrwxrwx 2 1002 0 4096 Jul 14 16:31 .
drwxrwxrwx 5 0 0 4096 Jul 13 13:46 ..
-rw-r--r-- 1 1001 0 0 Jul 14 15:45 newfile
-rw-r--r-- 1 0 0 0 Jul 14 15:52 newfile2
-rw-r--r-- 1 65534 4294967294 0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# chown root newfile3
chown: changing ownership of 'newfile3': Operation not permitted
Alternativ können NTFS-ACLs in Dual-Protokoll-Umgebungen verwendet werden, um den Stammzugriff präzise zu beschränken.