Oracle Solaris ZFS-Administrationshandbuch

Kapitel 8 Schützen von Oracle Solaris ZFS-Dateien mit Zugriffssteuerungslisten

Dieses Kapitel enthält Informationen zum Arbeiten mit Zugriffssteuerungslisten. Diese Listen dienen zum Schutz von ZFS-Dateien. Zugriffssteuerungslisten definieren im Vergleich zu UNIX-Standardzugriffsrechten feiner abgestimmte Zugriffsrechte.

Dieses Kapitel enthält die folgenden Abschnitte:

Neues Solaris-Modell für Zugriffssteuerungslisten

Frühere Versionen des Betriebssystems Solaris unterstützten eine auf dem POSIX-Entwurf basierende Implementierung von Zugriffssteuerungslisten. POSIX-basierte Zugriffssteuerungslisten dienen zum Schutz von UFS-Dateien und werden von NFS-Versionen vor NFSv4 verwendet.

Seit der Einführung von NFSv4 unterstützt ein neues Modell für Zugriffssteuerungslisten vollständig die Interoperabilität, die NFSv4 für die Kommunikation zwischen UNIX-Clients und anderen Clients bietet. Die neue, in der NFSv4-Spezifikation definierte Implementierung von Zugriffssteuerungslisten bietet eine reichhaltigere Semantik, die auf NT-basierten Zugriffssteuerungslisten beruht.

Es folgen die wichtigsten Unterschiede des neuen Zugriffssteuerungslistenmodells:

Das neue Zugriffssteuerungslistenmodell basiert auf der NFSv4-Spezifikation und ist den NT-Zugriffssteuerungslistenmodellen ähnlich.
Das neue Modell bietet feiner abgestimmte Zugriffsrechte. Weitere Informationen finden Sie in Tabelle 8–2.
Zugriffssteuerungslisten werden mit den Befehlen chmod und ls anstatt setfacl und getfacl eingestellt und angezeigt.
Das neue Modell bietet eine reichhaltigere Vererbungssemantik zum Festlegen der Weitergabe von Zugriffsrechten von über- an untergeordnete Verzeichnisse usw. Weitere Informationen dazu finden Sie in Vererbung von Zugriffssteuerungslisten.

Beide Zugriffssteuerungslistenmodelle bieten eine feiner abstimmbare Kontrolle von Zugriffsrechten als die Standardzugriffsrechte. Ähnlich wie POSIX-basierten Zugriffssteuerungslisten bestehen auch die neuen Zugriffssteuerungslisten aus mehreren Zugriffssteuerungseinträgen.

POSIX-basierte Zugriffssteuerungslisten definieren mithilfe eines einzigen Eintrags, welche Zugriffsrechte zulässig und unzulässig sind. Das neue Zugriffssteuerungslistenmodell besitzt zwei Arten von Zugriffssteuerungseinträgen, die sich auf die Überprüfung von Zugriffsrechten auswirken: ALLOW (Erlauben) und DENY (Verweigern). Demzufolge können Sie nicht aus einem einzigen Zugriffssteuerungseintrag schließen, ob die in diesem Zugriffssteuerungseintrag nicht definierten Zugriffsrechte zulässig sind oder nicht.

Die Konvertierung zwischen NFSv4-basierten und POSIX-basierten Zugriffssteuerungslisten geschieht wie folgt:

Bei der Verwendung von Dienstprogrammen, die Zugriffsrechte überprüfen (z. B. die Befehle cp, mv, tar, cpio oder rcp), werden die POSIX-basierten Zugriffssteuerungslisten in die entsprechenden NFSv4-basierten Zugriffssteuerungslisten konvertiert, damit UFS-Dateien mit Zugriffssteuerungslisten in ein ZFS-Dateisystem transferiert werden können.
Einige NFSv4-basierte Zugriffssteuerungslisten werden in POSIX-basierte Zugriffssteuerungslisten konvertiert. Wenn eine NFSv4-basierte Zugriffssteuerungsliste nicht in eine POSIX-basierte Zugriffssteuerungsliste konvertiert werden kann, wird eine Meldung angezeigt, die der folgenden ähnlich ist:
# cp -p filea /var/tmp cp: failed to set acl entries on /var/tmp/filea
Wenn Sie auf einem System, auf dem die neueste Solaris-Version installiert ist, mit tar oder cpio ein UFS-Archiv mit der Option zur Beibehaltung der Zugriffssteuerungsliste (tar -p bzw. cpio -P) erstellen, gehen beim Extrahieren des Archivs auf einem System, auf dem eine frühere Solaris-Version installiert ist, die Zugriffssteuerungslisten verloren.

Alle Dateien werden mit den ordnungsgemäßen Dateimodi extrahiert, aber die Zugriffssteuerungslisten werden ignoriert.
Der Befehl ufsrestore ermöglicht es, Daten in einem ZFS-Dateisystem wiederherzustellen. Wenn die Originaldaten POSIX-basierte Zugriffssteuerungslisten enthalten, werden diese in NFSv4-basierte Zugriffssteuerungslisten konvertiert.
Wenn Sie versuchen, eine NFSv4-basierte Zugriffssteuerungsliste für eine UFS-Datei festzulegen, wird eine Meldung wie die folgende angezeigt:
chmod: ERROR: ACL type's are different
Wenn Sie versuchen, eine POSIX-basierte Zugriffssteuerungsliste für eine ZFS-Datei festzulegen, wird eine Meldung wie die folgende angezeigt:
# getfacl filea File system doesn't support aclent_t style ACL's. See acl(5) for more information on Solaris ACL support.

Informationen zu Einschränkungen mit Zugriffssteuerungslisten und Backup-Software finden Sie unter Sichern von ZFS-Daten mit anderen Softwarepaketen zur Erstellung von Sicherungskopien.

Syntaxbeschreibungen zum Setzen von Zugriffssteuerungslisten

Es gibt zwei grundlegende Zugriffssteuerungslistenformate:

Syntax zum Setzen gewöhnlicher Zugriffssteuerungslisten

Eine Zugriffssteuerungsliste ist insofern gewöhnlich, als sie nur die herkömmlichen UNIX-Einträge owner/group/other repräsentiert.

chmod [Optionen] A[Index]{+|=}owner@ |group@ |everyone@: Zugriffsrechte/...[:Vererbungsflags]: deny | allow Datei

chmod [Optionen] A-owner@, group@, everyone@: Zugriffsrechte/...[:Vererbungsflags]: deny | allow Datei ...

chmod [Optionen] A[Index]- Datei

Syntax zum Setzen komplexerer Zugriffssteuerungslisten

chmod [Optionen] A[Index]{+|=}user|group:name:Zugriffsrechte /...[:Vererbungsflags]:deny | allow Datei

chmod [Optionen] A-user|group:name:Zugriffsrechte /...[:Vererbungsflags]:deny | allow Datei ...

chmod [Optionen] A[Index]- Datei

owner@, group@, everyone@: Der Zugriffssteuerungslisten-Eintragstyp für die gewöhnliche Zugriffssteuerungslistensyntax. Eine Beschreibung der Zugriffssteuerungslisten-Eintragstypen finden Sie in Tabelle 8–1.
user oder group:Zugriffssteuerungslisten-Eintragstyp-ID = Benutzername oder Gruppenname: Der Zugriffssteuerungslisten-Eintragstyp für die explizite Zugriffssteuerungslistensyntax. Der Zugriffssteuerungslisten-Eintragstyp „user” bzw. ”group” muss auch die Zugriffssteuerungslisteneintrags-ID, den Benutzernamen oder den Gruppennamen enthalten. Eine Beschreibung der Zugriffssteuerungslisten-Eintragstypen finden Sie in Tabelle 8–1.
Zugriffsrechte/.../: Die Zugriffsrechte, die gewährt bzw. verweigert werden. Eine Beschreibung von Zugriffsrechten für Zugriffssteuerungslisten finden Sie in Tabelle 8–2.
Vererbungsflags: Eine optionale Liste von Vererbungsflags von Zugriffssteuerungslisten. Eine Beschreibung der Vererbungsflags von Zugriffssteuerungslisten finden Sie in Tabelle 8–3.
deny | allow: Legt fest, ob Zugriffsrechte gewährt oder verweigert werden.

Im folgenden Beispiel spielt die Zugriffssteuerungslisten-Eintragstyp-ID keine Rolle:

group@:write_data/append_data/execute:deny

Das folgende Beispiel enthält eine Zugriffssteuerungslisteneintrags-ID, da ein spezifischer Benutzer (Zugriffssteuerungslisten-Eintragstyp) in der Zugriffssteuerungsliste enthalten ist.

0:user:gozer:list_directory/read_data/execute:allow

Ein Zugriffssteuerungslisteneintrag sieht ungefähr wie folgt aus:

2:group@:write_data/append_data/execute:deny

Die 2 bzw. die Index-ID in diesem Beispiel identifiziert den Zugriffssteuerungslisteneintrag in der größeren Zugriffssteuerungsliste, in der für Eigentümer, spezifische UIDs, Gruppen und allgemeine Zugriffsrechte mehrere Einträge vorhanden sein können. Sie können die Index-ID mit dem Befehl chmod angeben und somit festlegen, welchen Teil der Zugriffssteuerungsliste Sie ändern möchten. Sie können beispielsweise Index-ID 3 als A3 im Befehl chmod angeben (siehe folgendes Beispiel):

chmod A3=user:venkman:read_acl:allow filename

Zugriffssteuerungslisten-Eintragstypen, die Eigentümer, Gruppen und andere Parameter in Zugriffssteuerungslisten darstellen, sind in der folgenden Tabelle beschrieben.

Tabelle 8–1 Zugriffssteuerungslisten- Eintragstypen


Zugriffssteuerungslisten- Eintragstyp	Beschreibung
`owner@`	Das Zugriffsrecht, das dem Eigentümer des Objekts gewährt wird.
`group@`	Das Zugriffsrecht, das der Eigentümergruppe des Objekts gewährt wird.
`everyone@`	Der Zugriff, der allen anderen Benutzern oder Gruppen gewährt wird, denen keine anderen Zugriffssteuerungslisteneinträge entsprechen.
`user`	Das Zugriffsrecht, das einem zusätzlichen (und durch den Benutzernamen anzugebenden) Benutzer des Objekts gewährt wird. Dieser Eintrag muss die Zugriffssteuerungslisteneintrags-ID enthalten, die wiederum den betreffenden `Benutzernamen` oder die `Benutzer-ID` enthält. Wenn es sich bei diesem Wert um keine gültige nummerische Benutzer-ID oder keinen `Benutzername` handelt, ist der Zugriffssteuerungslisten-Eintragstyp ungültig.
`group`	Das Zugriffsrecht, das einer zusätzlichen (und durch den Gruppennamen anzugebenden) Benutzergruppe des Objekts gewährt wird. Dieser Eintrag muss die Zugriffssteuerungslisteneintrags-ID enthalten, die wiederum den betreffenden `Gruppennamen` oder die `Gruppen-ID` enthält. Wenn es sich bei diesem Wert um keine gültige nummerische Gruppen-ID oder keinen `Gruppenname` handelt, ist der Zugriffssteuerungslisten-Eintragstyp ungültig.

In der folgenden Tabelle sind die Zugriffsrechte für Zugriffssteuerungslisten beschrieben.

Tabelle 8–2 Zugriffssteuerungslisten-Zugriffsrechte


Zugriffsrecht	Kurzform	Beschreibung
`add_file`	`w`	Berechtigung zum Hinzufügen neuer Dateien zu einem Verzeichnis.
`add_subdirectory`	`p`	Berechtigung zum Erstellen von Unterverzeichnissen in einem Verzeichnis.
`append_data`	`p`	Platzhalter. Gegenwärtig nicht implementiert.
`delete`	`d`	Berechtigung zum Löschen einer Datei.
`delete_child`	`D`	Berechtigung zum Löschen einer Datei oder eines Verzeichnisses in einem Verzeichnis.
`execute`	`x`	Berechtigung zum Ausführen einer Datei bzw. Durchsuchen eines Verzeichnisses.
`list_directory`	`r`	Berechtigung zum Auflisten des Inhalts eines Verzeichnisses.
`read_acl`	`c`	Berechtigung zum Lesen der Zugriffssteuerungsliste (`ls`).
`read_attributes`	`a`	Berechtigung zum Lesen grundlegender (nicht zu Zugriffssteuerungslisten gehörender) Attribute einer Datei. Grundlegende Attribute sind Attribute auf der stat-Ebene. Durch Setzen dieses Zugriffsmaskenbits kann eine Entität `ls`(1) und `stat`(2) ausführen.
`read_data`	`r`	Berechtigung zum Lesen des Inhalts einer a Datei.
`read_xattr`	`R`	Berechtigung zum Lesen der erweiterten Attribute einer Datei bzw. Durchsuchen des Verzeichnisses erweiterter Dateiattribute.
`synchronize`	`s`	Platzhalter. Gegenwärtig nicht implementiert.
`write_xattr`	`V`	Berechtigung zum Erstellen erweiterter Attribute bzw. Schreiben in das Verzeichnis erweiterter Attribute. Durch Gewähren dieses Zugriffsrechtes kann ein Benutzer für eine Datei ein Verzeichnis erweiterter Attribute erstellen. Die Zugriffsrechte der Attributdatei legen das Zugriffsrecht des Benutzers auf das Attribut fest.
`write_data`	`w`	Berechtigung zum Ändern oder Ersetzens des Inhalts einer Datei.
`write_attributes`	`I`	Berechtigung zum Setzen der Zeitmarken einer Datei bzw. eines Verzeichnisses auf einen beliebigen Wert.
`write_acl`	`A`	Berechtigung zum Schreiben bzw. Ändern der Zugriffsteuerungsliste mithilfe des Befehls `chmod`.
`write_owner`	`o`	Berechtigung zum Ändern des Eigentümers bzw. der Gruppe einer Datei bzw. Berechtigung zum Ausführen der Befehle `chown` oder `chgrp` für die betreffende Datei. Berechtigung zum Übernehmen der Eigentümerschaft einer Datei bzw. zum Ändern der ihrer Gruppe, zu der der betreffende Benutzer gehört. Wenn Sie die Benutzer- bzw. Gruppeneigentümerschaft auf einen beliebigen Benutzer bzw. eine beliebige Gruppe setzen wollen, ist das Zugriffsrecht `PRIV_FILE_CHOWN` erforderlich.

Vererbung von Zugriffssteuerungslisten

Der Zweck der Vererbung von Zugriffssteuerungslisten besteht darin, dass neu erstellte Dateien bzw. Verzeichnisse die vorgesehenen Zugriffssteuerungslisten erben, ohne dass die vorhandenen Zugriffsrechte des übergeordneten Verzeichnisses ignoriert werden.

Standardmäßig werden Zugriffssteuerungslisten nicht weitergegeben. Wenn Sie für ein Verzeichnis eine komplexe Zugriffssteuerungsliste setzen, wird diese nicht an untergeordnete Verzeichnisse vererbt. Sie müssen die Vererbung einer Zugriffssteuerungsliste für Dateien bzw. Verzeichnisse explizit angeben.

In der folgenden Tabelle sind die optionalen Vererbungsflags aufgeführt.

Tabelle 8–3 Vererbungsflags von Zugriffssteuerungslisten


Vererbungsflag	Kurzform	Beschreibung
`file_inherit`	`f`	Die Zugriffssteuerungsliste wird vom übergeordneten Verzeichnis nur an die Dateien des betreffenden Verzeichnisses vererbt.
`dir_inherit`	`d`	Die Zugriffssteuerungsliste wird vom übergeordneten Verzeichnis nur an die Unterverzeichnisse des betreffenden Verzeichnisses vererbt.
`inherit_only`	`i`	Die Zugriffssteuerungsliste wird vom übergeordneten Verzeichnis vererbt, gilt jedoch nur für neu erstellte Dateien bzw. Unterverzeichnisse, aber nicht für das betreffende Verzeichnis selbst. Für dieses Flag ist das Flag `file_inherit` bzw. `dir_inherit` (oder beide) erforderlich. Diese legen fest, was vererbt wird.
`no_propagate`	`n`	Die Zugriffssteuerungsliste wird vom übergeordneten Verzeichnis an die erste Hierarchieebene des betreffenden Verzeichnisses und nicht an untergeordnete Ebenen vererbt. Für dieses Flag ist das Flag `file_inherit` bzw. `dir_inherit` (oder beide) erforderlich. Diese legen fest, was vererbt wird.
`-`	entf.	Zugriff nicht gewährt.

Darüber hinaus können Sie mithilfe der Dateisystemeigenschaft aclinherit für das Dateisystem mehr oder weniger strenge Vererbungsrichtlinien für Zugriffssteuerungslisten festlegen. Weitere Informationen finden Sie im folgenden Abschnitt.

Eigenschaften von Zugriffssteuerungslisten

Das ZFS-Dateisystem enthält zwei Eigenschaften für Zugriffssteuerungslisten.

aclinherit – Diese Eigenschaft legt das Verhalten der Vererbung von Zugriffssteuerungslisten fest und kann die folgenden Werte annehmen:
- discard – Für neu erstellte Objekte werden beim Erstellen von Dateien und Verzeichnissen keine Zugriffssteuerungslisteneinträge vererbt. Die Zugriffssteuerungsliste der neuen Datei bzw. des neuen Verzeichnisses entspricht dem Zugriffsrechten dieser Datei bzw. dieses Verzeichnisses.
- noallow – Bei neuen Objekten werden nur vererbbare Zugriffssteuerungslisteneinträge mit Zugriffstyp deny vererbt.
- restricted – Für neu erstellte Objekte werden beim Vererben von Zugriffssteuerungslisteneinträgen die Zugriffsrechte write_owner und write_acl entfernt.
- passthrough – Ist der Eigenschaftswert auf passthrough gesetzt, werden die Dateien mithilfe von Zugriffsrechten erstellt, die durch die vererbbaren Zugriffssteuerungseinträge festgelegt wurden. Wenn keine Zugriffsrechte für die vererbbaren Zugriffssteuerungseinträge vorhanden sind, werden Zugriffsrechte gesetzt, die mit der Forderung der Anwendung übereinstimmen.
- passthrough-x – Dieser Eigenschaftswert hat die gleiche Semantik wie passthrough, mit der Ausnahme, dass bei Aktivierung von passthrough-x Dateien mit der Ausführungsberechtigung (x) erstellt werden, jedoch nur, wenn die Ausführungsberechtigung im Dateierstellungsmodus und in einer vererbbaren Zugriffssteuerungsliste festgelegt wurde, die sich auf den Modus auswirkt.
Der Standardwert für die Eigenschaft aclinherit ist beschränkt.
aclmode – Diese Eigenschaft ändert das Zugriffssteuerungslistenverhalten, wenn eine Datei neu erstellt wird oder die Datei- bzw. Verzeichniszugriffsrechte vom Befehl chmod geändert werden, und kann die folgenden Werte annehmen:
- discard – Alle Zugriffssteuerungslisteneinträge außer denen, die den Modus der Datei bzw. des Verzeichnisses definieren, werden entfernt.
- groupmask – Zugriffssteuerungslisten-Zugriffsrechte für Benutzer bzw. Gruppen werden eingeschränkt, sodass sie nicht größer werden als durch die Gruppenzugriffsrechte festgelegt, es sei denn, es handelt sich um einen Benutzereintrag mit der gleichen Benutzer-ID wie der Eigentümer der Datei bzw. des Verzeichnisses. Dann werden die Zugriffssteuerungslisten-Zugriffsrechte eingeschränkt, sodass sie nicht größer werden als durch die Zugriffsrechte des Eigentümers gesetzt.
- passthrough – Während eines chmod-Vorgangs werden Zugriffssteuerungseinträge außer owner@, group@ oder everyone@ nicht geändert. Zugriffssteuerungseinträge mit owner@, group@ oder everyone@ werden deaktiviert, um den Dateimodus wie durch den chmod-Vorgang gefordert zu setzen.
Der Standardwert für aclmode ist groupmask.

Setzen von Zugriffssteuerungslisten an ZFS-Dateien

In ZFS bestehen Zugriffssteuerungslisten aus Zugriffssteuerungslisteneinträgen. ZFS bietet ein reines Zugriffssteuerungslistenmodell, in dem alle Dateien eine Zugriffssteuerungsliste besitzen. Normalerweise sind solche Zugriffssteuerungslisten gewöhnlich, da sie nur die herkömmlichen UNIX-Einträge owner/group/other repräsentieren.

Wenn Sie also die Zugriffsrechte einer Datei ändern, wird die entsprechende Zugriffssteuerungsliste automatisch aktualisiert. Wenn Sie eine komplexe Zugriffssteuerungsliste entfernen, die einem Benutzer Zugriff auf eine Datei bzw. ein Verzeichnis gewährt, kann dieser Benutzer unter Umständen noch immer Zugriff auf diese Datei bzw. dieses Verzeichnis haben, da die Zugriffsrecht-Bits dieser Datei bzw. dieses Verzeichnisses einer Gruppe oder allen Benutzern Zugriff gewähren. Alle Entscheidungen in Sachen Zugriffskontrolle werden von den Zugriffsrechten der Zugriffssteuerungsliste dieser Datei bzw. dieses Verzeichnisses festgelegt.

Es folgen die grundlegenden Regeln für den Zugriff auf ZFS-Dateien mithilfe von Zugriffssteuerungslisten:

ZFS verarbeitet Zugriffssteuerungslisteneinträge in der Reihenfolge, wie sie in der Zugriffssteuerungsliste aufgeführt sind (d. h. von oben nach unten).
Es werden nur Zugriffssteuerungslisteneinträge berücksichtigt, deren Benutzer-ID mit der ID des Zugriff anfordernden Benutzer übereinstimmt.
Wenn ein Zugriffsrecht einmal gewährt wurde, kann es durch nachfolgende Zugriffssteuerungslisteneinträge in der gleichen Zugriffssteuerungsliste nicht mehr rückgängig gemacht werden.
Eigentümern von Dateien wird das Zugriffsrecht write_acl auch dann bedingungslos gewährt, wenn es in der Zugriffssteuerungsliste explizit verweigert wird. Nicht angegebene Zugriffsrechte werden verweigert.

Falls Zugriffsrechte verweigert werden bzw. Angaben zum Zugriff auf eine Datei fehlen, legen die Zugriffsrechte des betreffenden untergeordneten Systems fest, welche Rechte dem Eigentümer einer Datei bzw. dem Superuser gewährt werden. Dadurch wird verhindert, dass der Zugriff für Dateieigentümernicht gesperrt wird und Superuser Dateien aus Gründen der Wiederherstellung ändern können.

Wenn Sie für ein Verzeichnis eine komplexe Zugriffssteuerungsliste setzen, wird diese nicht automatisch an untergeordnete Verzeichnisse dieses Verzeichnisses vererbt. Wenn Sie für ein Verzeichnis eine komplexe Zugriffssteuerungsliste setzen und diese an die untergeordneten Verzeichnisse dieses Verzeichnisses vererbt werden soll, müssen Sie die Zugriffssteuerungslisten-Vererbungsflags verwenden. Weitere Informationen finden Sie in Tabelle 8–3 und unter Festlegen der Vererbung von Zugriffssteuerungslisten an ZFS-Dateien im ausführlichen Format.

Erstellen einer neuen Datei und (je nach dem Wert von umask) einer gewöhnlichen Standard-Zugriffssteuerungsliste ähnlich wie im folgenden Beispiel:

$ ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 14:09 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Bitte beachten Sie, dass in diesem Beispiel jede Benutzerkategorie (owner@, group@, everyone@) zwei Zugriffssteuerungslisteneinträge besitzt. Ein Eintrag gilt für die Verweigerung (deny), der andere zum Gewähren (allow) von Zugriffsrechten.

Es folgt eine Beschreibung dieser Datei-Zugriffssteuerungsliste:

0:owner@: Dem Eigentümer wird das Ausführen der Datei verweigert (execute:deny).
1:owner@: Der Eigentümer kann den Dateiinhalt lesen und ändern ( read_data/write_data/append_data). Der Eigentümer kann darüber hinaus auch Dateiattribute wie z. B. Zeitmarken, erweiterte Attribute und Zugriffssteuerungslisten ändern (write_xattr/write_attributes /write_acl). Zusätzlich dazu kann der Eigentümer die Datei-Eigentümerschaft ändern (write_owner:allow).
2:group@: Der Gruppe wird das Ausführen der Datei verweigert (write_data/append_data/execute:deny).
3:group@: Der Gruppe wird die Berechtigung zum Lesen der Datei gewährt (read_data:allow).
4:everyone@: Benutzern, die nicht Eigentümer der Datei sind oder nicht zur Gruppe der Dateieigentümer gehören, wird die Berechtigung zum Ausführen und Ändern des Inhalts der Datei bzw. Ändern von Dateiattributen verweigert (write_data/append_data/write_xattr/execute/write_attributes/write_acl/write_owner:deny ).
5:everyone@: Benutzern, die nicht Eigentümer der Datei sind oder nicht zur Gruppe der Dateieigentümer gehören, wird die Berechtigung zum Lesen der Datei bzw. der Dateiattribute gewährt (read_data/read_xattr/read_attributes/read_acl/synchronize:allow ). Das Zugriffsrecht synchronize ist zurzeit nicht implementiert.

Erstellen eines neuen Verzeichnisses und (je nach dem Wert von umask) einer Standardverzeichnis-Zugriffssteuerungsliste ähnlich wie im folgenden Beispiel:

$ ls -dv dir.1
drwxr-xr-x   2 root     root           2 May 20 14:11 dir.1
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Es folgt eine Beschreibung dieser Verzeichnis-Zugriffssteuerungsliste:

0:owner@: Die Verweigerungsliste für den Eigentümer ist leer (::deny).
1:owner@: Der Eigentümer kann den Inhalt des Verzeichnisses lesen und ändern (list_directory/read_data/add_file/write_data/add_subdirectory/append_data ), durchsuchen Sie die Inhalte (execute), und ändern Sie die Verzeichnisattribute wie z. B. Zeitmarken, erweiterte Attribute und Zugriffssteuerungslisten ( write_xattr/write_attributes/write_acl). Zusätzlich dazu kann der Eigentümer die Verzeichnis-Eigentümerschaft ändern (write_owner:allow).
2:group@: Die Gruppe kann den Verzeichnisinhalt weder erweitern noch ändern ( add_file/write_data/add_subdirectory/append_data:deny).
3:group@: Die Gruppe kann den Verzeichnisinhalt auflisten und lesen. Darüber hinaus kann die Gruppe kann den Verzeichnisinhalt auch durchsuchen (list_directory/read_data/execute:allow ).
4:everyone@: Benutzern, die nicht Eigentümer der Datei sind oder nicht zur Gruppe der Dateieigentümer gehören, wird die Berechtigung zum Erweitern bzw. Ändern des Verzeichnisinhalts verweigert (add_file/write_data/add_subdirectory/append_data). Außerdem wird die Berechtigung zum Ändern von Verzeichnisattributen verweigert (write_xattr/write_attributes/write_acl/write_owner:deny).
5:everyone@: Benutzern, die nicht Eigentümer der Datei sind oder nicht zur Gruppe der Dateieigentümer gehören, wird die Berechtigung zum Lesen und Ausführen des Verzeichnisinhalts und der Verzeichnisattribute gewährt (read_data/read_xattr/read_attributes/read_acl/attributes/read_acl/synchronize:allow ). Das Zugriffsrecht synchronize ist zurzeit nicht implementiert.

Setzen und Anzeigen von Zugriffssteuerungslisten an ZFS-Dateien im ausführlichen Format

Mit dem Befehl chmod können Sie Zugriffssteuerungslisten von ZFS-Dateien ändern. Die folgende chmod-Syntax zum Ändern von Zugriffssteuerungslisten nutzt zur Erkennung des Zugriffssteuerungslistenformats die Zugriffssteuerungslisten-Spezifikation. Eine Beschreibung der Zugriffssteuerungslisten-Spezifikation finden Sie unter Syntaxbeschreibungen zum Setzen von Zugriffssteuerungslisten.

Hinzufügen von Zugriffssteuerungslisten-Eintragstypen
- Hinzufügen eines Zugriffssteuerungslisten-Eintrags für einen Benutzer
  % chmod A+acl-specification filename
- Hinzufügen eines Zugriffssteuerungslisten-Eintrags nach Index-ID
  % chmod Aindex-ID+acl-specification filename
  Mit dieser Syntax wird der neue Zugriffssteuerungslisten-Eintrag an der entspechenden Index-ID eingefügt.

Ersetzen eines Zugriffssteuerungslisten-Eintrags

% chmod A=acl-specification filename

% chmod Aindex-ID=acl-specification filename

Entfernen von Zugriffssteuerungslisten-Einträgen
- Entfernen eines Zugriffssteuerungslisten-Eintrags nach Index-ID
  % chmod Aindex-ID- filename
- Entfernen eines Zugriffssteuerungslisten-Eintrags nach Benutzername
  % chmod A-acl-specification filename
- Entfernen aller komplexen Zugriffssteuerungslisten-Einträge aus einer Datei
  % chmod A- filename

Ausführliche Informationen zu Zugriffssteuerungslisten werden mithilfe des Befehls ls - v angezeigt. Beispiel:

# ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 14:09 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Informationen zur Verwendung des Zugriffssteuerungslisten-Kompaktformats finden Sie unter Setzen und Anzeigen von Zugriffssteuerungslisten an ZFS-Dateien im Kompaktformat.

Beispiel 8–1 Ändern gewöhnlicher Zugriffssteuerungslisten an ZFS-Dateien

Dieser Abschnitt enthält Beispiele zum Setzen und Anzeigen gewöhnlicher Zugriffssteuerungslisten.

Im folgenden Beispiel besitzt Datei.1 eine gewöhnliche Zugriffssteuerungsliste:

# ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 15:03 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Im folgenden Beispiel wird die Berechtigung write_data für group@ gewährt:

# chmod A2=group@:append_data/execute:deny file.1
# chmod A3=group@:read_data/write_data:allow file.1
# ls -v file.1
-rw-rw-r--   1 root     root      206663 May 20 15:03 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:append_data/execute:deny
     3:group@:read_data/write_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Im folgenden Beispiel werden die Berechtigungen an Datei.1 auf 644 zurückgesetzt.

# chmod 644 file.1
# ls -v file.1
-rw-r--r--   1 root     root      206663 May 20 15:03 file.1
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Beispiel 8–2 Setzen komplexer Zugriffssteuerungslisten an ZFS-Dateien

Dieser Abschnitt enthält Beispiele zum Setzen und Anzeigen komplexer Zugriffssteuerungslisten.

Im folgenden Beispiel werden die Berechtigungen read_data/execute für den Benutzer gozer und das Verzeichnis test.dir gesetzt:

# chmod A+user:gozer:read_data/execute:allow test.dir
# ls -dv test.dir
drwxr-xr-x+  2 root     root           2 May 20 15:09 test.dir
     0:user:gozer:list_directory/read_data/execute:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Im folgenden Beispiel werden die Berechtigungen read_data/execute für den Benutzer gozer entfernt:

# chmod A0- test.dir
# ls -dv test.dir
drwxr-xr-x   2 root     root           2 May 20 15:09 test.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Beispiel 8–3 Interaktion von Zugriffssteuerungslisten mit Berechtigungen an ZFS-Dateien

Diese Beispiele demonstrieren die Interaktion zwischen dem Setzen von Zugriffssteuerungslisten und dem anschließenden Ändern der Berechtigungen einer Datei bzw. eines Verzeichnisses.

Im folgenden Beispiel besitzt Datei.2 eine gewöhnliche Zugriffssteuerungsliste:

# ls -v file.2
-rw-r--r--   1 root     root        3103 May 20 15:23 file.2
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Im folgenden Beispiel werden gewährte Zugriffssteuerungslisten-Berechtigungen vom Benutzer everyone@ entfernt:

# chmod A5- file.2
# ls -v file.2
-rw-r-----+  1 root     root        3103 May 20 15:23 file.2
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny

In dieser Ausgabe werden die Dateiberechtigungen von 644 auf 640 zurückgesetzt. Leseberechtigungen für everyone@ werden faktisch von den Dateiberechtigungen entfernt, wenn die gewährten Zugriffssteuerungslisten-Zugriffsrechte für everyone@ entfernt werden.

Im folgenden Beispiel wird die vorhandene Zugriffssteuerungsliste mit den Zugriffsrechten read_data/write_data für everyone@ ersetzt:

# chmod A=everyone@:read_data/write_data:allow file.3
# ls -v file.3
-rw-rw-rw-+  1 root     root        6986 May 20 15:25 file.3
     0:everyone@:read_data/write_data:allow

In dieser Ausgabe ersetzt die chmod-Syntax faktisch die Zugriffssteuerungsliste mit den Berechtigungen read_data/write_data:allow durch Lese- und Schreibberechtigungen für Eigentümer, Gruppen und everyone@ . In diesem Modell gibt everyone@ den Zugriff für beliebige Benutzer bzw. Gruppen an. Da keine Zugriffssteuerungslisteneinträge für owner@ bzw. group@ vorhanden sind, die die Zugriffsrechte für Eigentümer und Gruppen überschreiben könnten, werden die Berechtigungen auf 666 gesetzt.

Im folgenden Beispiel wird die vorhandene Zugriffssteuerungsliste mit Leseberechtigungen für den Benutzer gozer ersetzt:

# chmod A=user:gozer:read_data:allow file.3
# ls -v file.3
----------+  1 root     root        6986 May 20 15:25 file.3
     0:user:gozer:read_data:allow

In diesem Beispiel werden die Dateizugriffsrechte mit 000 berechnet, da für owner@, group@ bzw. everyone@ keine Zugriffssteuerungslisteneinträge vorhanden sind, die die herkömmlichen Berechtigungskomponenten einer Datei repräsentieren. Der Dateieigentümer kann dieses Problem durch Zurücksetzen der Zugriffsrechte (und der Zugriffssteuerungsliste) wie folgt beheben:

# chmod 655 file.3
# ls -v file.3
-rw-r-xr-x+  1 root     root        6986 May 20 15:25 file.3
     0:user:gozer::deny
     1:user:gozer:read_data:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data:deny
     5:group@:read_data/execute:allow
     6:everyone@:write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/execute/read_attributes/read_acl
         /synchronize:allow

Beispiel 8–4 Wiederherstellen gewöhnlicher Zugriffssteuerungslisten an ZFS-Dateien

Mit dem Befehl chmod können Sie alle komplexen Zugriffssteuerungslisten einer Datei bzw. eines Verzeichnisses entfernen und dadurch die gewöhnlichen Zugriffssteuerungslisten einer Datei oder eines Verzeichnisses wiederherstellen.

Im folgenden Beispiel besitzt test5.dir zwei komplexe Zugriffssteuerungseinträge:

# ls -dv test5.dir
drwxr-xr-x+  2 root     root           2 May 20 15:32 test5.dir
     0:user:lp:read_data:file_inherit:deny
     1:user:gozer:read_data:file_inherit:deny
     2:owner@::deny
     3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     4:group@:add_file/write_data/add_subdirectory/append_data:deny
     5:group@:list_directory/read_data/execute:allow
     6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Im folgenden Beispiel werden die komplexen Zugriffsteuerungslisten für die Benutzer gozer und lp entfernt. Die verbleibende Zugriffsteuerungsliste enthält de sechs Standardwerte für owner@, group@ und everyone@.

# chmod A- test5.dir
# ls -dv test5.dir
drwxr-xr-x   2 root     root           2 May 20 15:32 test5.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Festlegen der Vererbung von Zugriffssteuerungslisten an ZFS-Dateien im ausführlichen Format

Sie können festlegen, ob und wie Zugriffsteuerungslisten von Dateien und Verzeichnissen vererbt werden sollen. Standardmäßig werden Zugriffssteuerungslisten nicht weitergegeben. Wenn Sie für ein Verzeichnis eine komplexe Zugriffssteuerungsliste setzen, wird diese nicht an untergeordnete Verzeichnisse vererbt. Sie müssen die Vererbung einer Zugriffssteuerungsliste für Dateien oder Verzeichnisse explizit angeben.

Darüber hinaus können zwei Eigenschaften von Zugriffssteuerungslisten in Dateisystemen global gesetzt werden: aclinherit und aclmode. Standardmäßig ist aclinherit auf restricted und aclmode auf groupmask gesetzt .

Weitere Informationen dazu finden Sie in Vererbung von Zugriffssteuerungslisten.

Beispiel 8–5 Gewähren der Standardvererbung von Zugriffssteuerungslisten

Standardmäßig werden Zugriffssteuerungslisten nicht durch eine Verzeichnisstruktur weitergegeben.

Im folgenden Beispiel wird eine komplexe Zugriffssteuerungsliste mit den Zugriffsrechten read_data/write_data/execute für den Benutzer gozer des Verzeichnisses test.dir gesetzt:

# chmod A+user:gozer:read_data/write_data/execute:allow test.dir
# ls -dv test.dir
drwxr-xr-x+  2 root     root           2 May 20 15:41 test.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Beim Erstellen eines Unterverzeichnisses in test.dir wird die Zugriffssteuerungsliste für den Benutzer gozer nicht weitergegeben. Der Benutzer gozer hätte nur dann Zugriff auf das Unterverzeichnis, wenn ihm die Berechtigungen für das Unterverzeichnis Zugriff als Dateieigentümer, Gruppenmitglied oder everyone@ gewähren würden. Beispiel:

# mkdir test.dir/sub.dir
# ls -dv test.dir/sub.dir
drwxr-xr-x   2 root     root           2 May 20 15:42 test.dir/sub.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Beispiel 8–6 Gewähren der Vererbung von Zugriffssteuerungslisten an Dateien und Verzeichnissen

In den folgenden Beispielen sind die Zugriffssteuerungslisten für Dateien und Verzeichnisse aufgeführt, die beim Setzen des Flags file_inherit angewendet werden.

Im folgenden Beispiel werden die Zugriffsrechte read_data/write_data für den Benutzer gozer des Verzeichnisses test2.dir hinzugefügt, sodass dieser Benutzer Leseberechtigung für neu erstellte Dateien besitzt:

# chmod A+user:gozer:read_data/write_data:file_inherit:allow test2.dir
# ls -dv test2.dir
drwxr-xr-x+  2 root     root           2 May 20 15:50 test2.dir
     0:user:gozer:read_data/write_data:file_inherit:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Im folgenden Beispiel werden die Zugriffsrechte des Benutzers gozer auf die neu erstellte Datei test2.dir/file.2 angewendet. Durch die gewährte Zugriffssteuerungslisten-Vererbung read_data:file_inherit:allow hat der Benutzer gozer Leseberechtigung für den Inhalt neu erstellter Dateien.

# touch test2.dir/file.2
# ls -v test2.dir/file.2
-rw-r--r--+  1 root     root           0 May 20 15:51 test2.dir/file.2
     0:user:gozer:write_data:deny
     1:user:gozer:read_data/write_data:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Da die Eigenschaft aclmode für diese Datei auf den Standardwert groupmask gesetzt ist, hat der Benutzer gozer für die Datei file.2 nicht das Zugriffsrecht write_data, da es die Gruppenberechtigung der Datei nicht zulässt.

Das Zugriffsrecht inherit_only, das beim Setzen des Flags file_inherit oder dir_inherit angewendet wird, dient zum Weitergeben der Zugriffssteuerungsliste durch die Verzeichnisstruktur. Somit werden dem Benutzer gozer nur Zugriffsrechte für everyone@ gewährt bzw. verweigert, wenn er nicht Eigentümer der betreffenden Datei ist bzw. nicht zur Eigentümergruppe gehört. Beispiel:

# mkdir test2.dir/subdir.2
# ls -dv test2.dir/subdir.2
drwxr-xr-x+  2 root     root           2 May 20 15:52 test2.dir/subdir.2
     0:user:gozer:list_directory/read_data/add_file/write_data:file_inherit
         /inherit_only:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

In den folgenden Beispielen sind die Zugriffssteuerungslisten für Dateien und Verzeichnisse aufgeführt, die beim Setzen des Flags file_inherit und dir_inherit angewendet werden.

Im folgenden Beispiel werden dem Benutzer gozer Lese-, Schreib- und Ausführungsberechtigungen gewährt, die für neu erstellte Dateien und Verzeichnisse vererbt wurden:

# chmod A+user:gozer:read_data/write_data/execute:file_inherit/dir_inherit:allow 
test3.dir
# ls -dv test3.dir
drwxr-xr-x+  2 root     root           2 May 20 15:53 test3.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :file_inherit/dir_inherit:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

# touch test3.dir/file.3
# ls -v test3.dir/file.3
-rw-r--r--+  1 root     root           0 May 20 15:58 test3.dir/file.3
     0:user:gozer:write_data/execute:deny
     1:user:gozer:read_data/write_data/execute:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

# mkdir test3.dir/subdir.1
# ls -dv test3.dir/subdir.1
drwxr-xr-x+  2 root     root           2 May 20 15:59 test3.dir/subdir.1
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :file_inherit/dir_inherit/inherit_only:allow
     1:user:gozer:add_file/write_data:deny
     2:user:gozer:list_directory/read_data/add_file/write_data/execute:allow
     3:owner@::deny
     4:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     5:group@:add_file/write_data/add_subdirectory/append_data:deny
     6:group@:list_directory/read_data/execute:allow
     7:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     8:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Da die Zugriffsrechte des übergeordneten Verzeichnisses für group@ und everyone@ Schreib- und Ausführungsberechtigungen verweigern, wird in diesem Beispiel dem Benutzer gozer ebenfalls die Schreib- und Ausführungsberechtigung verweigert. Der Standardwert der Eigenschaft aclinherit ist restricted, was bedeutet, dass die Zugriffsrechte write_data und execute nicht vererbt werden.

Im folgenden Beispiel werden dem Benutzer gozer Lese-, Schreib- und Ausführungsberechtigungen gewährt, die für neu erstellte Dateien vererbt wurden. Diese Berechtigungen werden jedoch nicht an nachfolgende Verzeichnisinhalte weitergegeben.

# chmod A+user:gozer:read_data/write_data/execute:file_inherit/no_propagate:allow 
test4.dir
# ls -dv test4.dir
drwxr-xr-x+  2 root     root           2 May 20 16:02 test4.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :file_inherit/no_propagate:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Wie das folgende Beispiel zeigt, werden beim Erstellen eines neuen Unterverzeichnisses die Zugriffsrechte read_data/write_data/execute für den Benutzer gozer nicht an das neue Verzeichnis sub4.dir weitergegeben:

mkdir test4.dir/sub4.dir
# ls -dv test4.dir/sub4.dir
drwxr-xr-x   2 root     root           2 May 20 16:03 test4.dir/sub4.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data:deny
     3:group@:list_directory/read_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Wie das folgende Beispiel zeigt, werden die Zugriffsrechte read_data/write_data/execute für den Benutzer gozer an die neu erstellte Datei weitergegeben:

# touch test4.dir/file.4
# ls -v test4.dir/file.4
-rw-r--r--+  1 root     root           0 May 20 16:04 test4.dir/file.4
     0:user:gozer:write_data/execute:deny
     1:user:gozer:read_data/write_data/execute:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Beispiel 8–7 Vererbung der Zugriffssteuerungsliste mit der Eigenschaft `aclmode`, die auf `passthrough` gesetzt ist

Wenn die Eigenschaft aclmode des Dateisystems tank/cindys auf passthrough gesetzt ist, erbt der Benutzer gozer die auf das Verzeichnis test4.dir angewendete Zugriffssteuerungsliste für die neu erstellte Datei file.4, wie das folgende Beispiel zeigt:

# zfs set aclmode=passthrough tank/cindys
# touch test4.dir/file.4
# ls -v test4.dir/file.4
-rw-r--r--+  1 root     root           0 May 20 16:08 test4.dir/file.4
     0:user:gozer:write_data/execute:deny
     1:user:gozer:read_data/write_data/execute:allow
     2:owner@:execute:deny
     3:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     4:group@:write_data/append_data/execute:deny
     5:group@:read_data:allow
     6:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Diese Ausgabe zeigt, dass die für das übergeordnete Verzeichnis test4.dir gesetzte Zugriffssteuerungsliste read_data/write_data/execute:allow:file_inherit/dir_inherit an den Benutzer gozer weitergegeben wird.

Beispiel 8–8 Vererbung der Zugriffssteuerungsliste mit der Eigenschaft `aclmode`, die auf `discard` gesetzt ist

Wenn die Eigenschaft aclmode eines Dateisystems auf discard gesetzt ist, können Zugriffssteuerungslisten potenziell ignoriert werden, wenn sich die Zugriffsrechte eines Verzeichnisses ändern. Beispiel:

# zfs set aclmode=discard tank/cindys
# chmod A+user:gozer:read_data/write_data/execute:dir_inherit:allow test5.dir
# ls -dv test5.dir
drwxr-xr-x+  2 root     root           2 May 20 16:09 test5.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute
         :dir_inherit:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Wenn Sie später die Zugriffsrechte an einem Verzeichnis einschränken, gilt die komplexe Zugriffssteuerungsliste nicht mehr. Beispiel:

# chmod 744 test5.dir
# ls -dv test5.dir
drwxr--r--   2 root     root           2 May 20 16:09 test5.dir
     0:owner@::deny
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     2:group@:add_file/write_data/add_subdirectory/append_data/execute:deny
     3:group@:list_directory/read_data:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /execute/write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/read_attributes/read_acl
         /synchronize:allow

Beispiel 8–9 Vererbung der Zugriffssteuerungsliste mit der Eigenschaft `aclinherit`, die auf `noallow` gesetzt ist

Im folgenden Beispiel sind zwei komplexe Zugriffsteuerungslisten mit Dateivererbung gesetzt. Eine Zugriffssteuerungsliste gewährt die Berechtigung read_data, und die andere Zugriffssteuerungsliste verweigert die Berechtigung read_data. Dieses Beispiel zeigt auch, wie Sie mit dem gleichen Aufruf des Befehls chmod zwei Zugriffssteuerungseinträge angeben können.

# zfs set aclinherit=noallow tank/cindys
# chmod A+user:gozer:read_data:file_inherit:deny,user:lp:read_data:file_inherit:allow 
test6.dir
# ls -dv test6.dir
drwxr-xr-x+  2 root     root           2 May 20 16:11 test6.dir
     0:user:gozer:read_data:file_inherit:deny
     1:user:lp:read_data:file_inherit:allow
     2:owner@::deny
     3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     4:group@:add_file/write_data/add_subdirectory/append_data:deny
     5:group@:list_directory/read_data/execute:allow
     6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Wie das folgende Beispiel zeigt, gilt beim Erstellen einer neuen Datei die Zugriffssteuerungsliste, die das Zugriffsrecht read_data gewährt, nicht mehr.

# touch test6.dir/file.6
# ls -v test6.dir/file.6
-rw-r--r--   1 root     root           0 May 20 16:13 test6.dir/file.6
     0:owner@:execute:deny
     1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
         /write_acl/write_owner:allow
     2:group@:write_data/append_data/execute:deny
     3:group@:read_data:allow
     4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
         /write_acl/write_owner:deny
     5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Setzen und Anzeigen von Zugriffssteuerungslisten an ZFS-Dateien im Kompaktformat

Sie können Zugriffsrechte an ZFS-Dateien in einem Kompaktformat setzen und anzeigen, das für die einzelnen Berechtigungen 14 eindeutige Buchstaben verwendet. Die Buchstaben zur kompakten Darstellung der Zugriffsrechte sind in Tabelle 8–2 und Tabelle 8–3 aufgeführt.

Kompaktausgaben von Zugriffssteuerungslisten für Dateien und Verzeichnisse werden mithilfe des Befehls ls - V angezeigt. Beispiel:

# ls -V file.1
-rw-r--r--   1 root     root      206663 Jun 17 10:07 file.1
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Es folgt eine Beschreibung dieser Kompaktausgabe:

owner@: Dem Eigentümer wird das Ausführen der Datei verweigert (x= execute).
owner@: Der Eigentümer kann den Dateiinhalt lesen und ändern ( rw=read_data/write_data), (p= append_data). Der Eigentümer kann darüber hinaus auch Dateiattribute wie z. B. Zeitmarken, erweiterte Attribute und Zugriffssteuerungslisten ändern (A=write_xattr , W=write_attributes und C= write_acl). Zusätzlich dazu kann der Eigentümer die Datei-Eigentümerschaft ändern (o=write_owner).
group@: Der Gruppe werden Änderungs- und Ausführungsberechtigung für die Datei verweigert (write_data, p= append_data und x=execute).
group@: Der Gruppe wird die Berechtigung zum Lesen der Datei gewährt (r= read_data).
everyone@: Benutzern, die nicht Eigentümer der Datei sind oder nicht zur Gruppe der Dateieigentümer gehören, wird die Berechtigung zum Ausführen und Ändern des Dateiinhalts sowie Ändern von Dateiattributen verweigert (w=write_data, x= execute, p=append_data, A=write_xattr, W=write_attributes , C=write_acl und o= write_owner).
everyone@: Benutzer, die nicht Eigentümer der Datei bzw. der Dateiattribute sind oder nicht zur Gruppe der Eigentümer der Datei bzw. der Dateiattribute gehören (r=read_data, a=append_data, R=read_xattr , c=read_acl und s= synchronize). Das Zugriffsrecht synchronize ist zurzeit nicht implementiert.

Das Kompaktformat von Zugriffssteuerungslisten hat gegenüber dem ausführlichen Format folgende Vorteile:

Zugriffsrechte können für den Befehl chmod als positionale Argumente angegeben werden.
Der Bindestrich (-), der für die Verweigerung von Zugriffsrechten steht, kann weggelassen werden. Nur die erforderlichen Buchstaben müssen angegeben werden.
Zugriffsrechte und Vererbungsflags werden in der gleichen Weise gesetzt.

Informationen zur Verwendung des ausführlichen Formats von Zugriffssteuerungslisten finden Sie unter Setzen und Anzeigen von Zugriffssteuerungslisten an ZFS-Dateien im ausführlichen Format.

Beispiel 8–10 Setzen und Anzeigen von Zugriffssteuerungslisten im Kompaktformat

Im folgenden Beispiel ist eine gewöhnliche Zugriffssteuerungsliste für file.1 vorhanden:

# ls -V file.1
-rw-r--r--   1 root     root      206663 Jun 17 10:07 file.1
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Im diesem Beispiel werden die Berechtigungen read_data/execute für den Benutzer gozer der Datei.1 hinzugefügt:

# chmod A+user:gozer:rx:allow file.1
# ls -V file.1
-rw-r--r--+  1 root     root      206663 Jun 17 10:07 file.1
        user:gozer:r-x-----------:------:allow
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Eine andere Methode zum Hinzufügen der gleichen Zugriffsrechte für den Benutzer gozer besteht im Einfügen eines neuen Zugriffssteuerungslisteneintrags an einer neuen Position (z. B. Position 4). Somit werden die vorhandenen Zugriffssteuerungslisten an den Positionen 4-6 nach unten verschoben. Beispiel:

# chmod A4+user:gozer:rx:allow file.1
# ls -V file.1
-rw-r--r--+  1 root     root      206663 Jun 17 10:16 file.1
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
        user:gozer:r-x-----------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Im folgenden Beispiel werden dem Benutzer gozer Lese-, Schreib- und Ausführungsberechtigungen gewährt, die für neu erstellte Dateien und Verzeichnisse vererbt wurden.

# chmod A+user:gozer:rwx:fd:allow dir.2
# ls -dV dir.2
drwxr-xr-x+  2 root     root           2 Jun 17 10:19 dir.2
        user:gozer:rwx-----------:fd----:allow
            owner@:--------------:------:deny
            owner@:rwxp---A-W-Co-:------:allow
            group@:-w-p----------:------:deny
            group@:r-x-----------:------:allow
         everyone@:-w-p---A-W-Co-:------:deny
         everyone@:r-x---a-R-c--s:------:allow

Sie können Zugriffsrechte und Vererbungsflags auch aus der Ausgabe des Befehls ls - V in das Kompaktformat des Befehls chmod kopieren. Wenn Sie beispielsweise die Zugriffsrechte und Vererbungsflags von dir.2 für den Benutzer gozer auf den Benutzer cindys von dir.2 übertragen möchten, müssen Sie die entsprechenden Zugriffsrechte und Vererbungsflags (rwx-----------:f-----:allow ) in den Befehl chmod kopieren:

# chmod A+user:cindys:rwx-----------:fd----:allow dir.2
# ls -dV dir.2
drwxr-xr-x+  2 root     root           2 Jun 17 10:19 dir.2
       user:cindys:rwx-----------:fd----:allow
        user:gozer:rwx-----------:fd----:allow
            owner@:--------------:------:deny
            owner@:rwxp---A-W-Co-:------:allow
            group@:-w-p----------:------:deny
            group@:r-x-----------:------:allow
         everyone@:-w-p---A-W-Co-:------:deny
         everyone@:r-x---a-R-c--s:------:allow

Beispiel 8–11 Vererbung der Zugriffssteuerungsliste mit der Eigenschaft `aclinherit`, die auf `passthrough` gesetzt ist

Wenn die Eigenschaft aclinherit des Dateisystems auf passthrough gesetzt ist, werden alle vererbbaren Zugriffssteuerungslisten ohne jegliche Änderung der Einträge bei der Vererbung weitergegeben. Ist diese Eigenschaft auf passthrough gesetzt, werden Dateien mit Berechtigungen erstellt, die von der vererbbaren Zugriffssteuerungsliste bestimmt werden. Wenn keine Zugriffsrechte für die vererbbaren Zugriffssteuerungseinträge vorhanden sind, werden Zugriffsrechte gesetzt, die mit der Forderung der Anwendung übereinstimmen.

In den folgenden Beispielen wird die Vererbung von Berechtigungen durch das Setzen der Eigenschaft aclinherit auf passthrough in kompakter Zugriffssteuerungslistensyntax veranschaulicht.

In diesem Beispiel wird eine Zugriffssteuerungsliste für das Verzeichnis test1.dir gesetzt, um die Vererbung zu erzwingen. Durch die Syntax wird für neu erstellte Dateien ein Zugriffssteuerungseintrag owner@, group@ und everyone@ erstellt. Neu erstellte Verzeichnisse erben die Zugriffssteuerungseinträge @owner, group@ und everyone@. Darüber hinaus erben Verzeichnisse sechs weitere Zugriffssteuerungseinträge, die die Einträge an neu erstellte Verzeichnisse und Dateien weitergeben.

# zfs set aclinherit=passthrough tank/cindys
# pwd
/tank/cindys
# mkdir test1.dir

# chmod A=owner@:rwxpcCosRrWaAdD:fd:allow,group@:rwxp:fd:allow,everyone@::fd:allow 
test1.dir
# ls -Vd test1.dir
drwxrwx---+  2 root     root           2 Jun 17 10:37 test1.dir
            owner@:rwxpdDaARWcCos:fd----:allow
            group@:rwxp----------:fd----:allow
         everyone@:--------------:fd----:allow

In diesem Beispiel erbt eine neu erstellte Datei die Zugriffssteuerungsliste, die für die Weitergabe an neu erstellte Dateien angegeben wurde.

# cd test1.dir
# touch file.1
# ls -V file.1
-rwxrwx---+  1 root     root           0 Jun 17 10:38 file.1
            owner@:rwxpdDaARWcCos:------:allow
            group@:rwxp----------:------:allow
         everyone@:--------------:------:allow

In diesem Beispiel erbt ein neu erstelltes Verzeichnis sowohl die Zugriffssteuerungseinträge, die den Zugriff auf dieses Verzeichnis regeln, als auch diejenigen für die künftige Weitergabe an untergeordnete Objekte des neu erstellten Verzeichnisses.

# mkdir subdir.1
# ls -dV subdir.1
drwxrwx---+  2 root     root           2 Jun 17 10:39 subdir.1
            owner@:rwxpdDaARWcCos:fdi---:allow
            owner@:rwxpdDaARWcCos:------:allow
            group@:rwxp----------:fdi---:allow
            group@:rwxp----------:------:allow
         everyone@:--------------:fdi---:allow
         everyone@:--------------:------:allow

Die Einträge -di-- und f-i--- gelten für die Weitergabe der Vererbung und werden bei der Zugriffssteuerung nicht berücksichtigt. In diesem Beispiel wird eine Datei mit einer gewöhnlichen Zugriffssteuerungsliste in einem anderen Verzeichnis erstellt, wo keine vererbten Zugriffssteuerungseinträge vorhanden sind.

# cd /tank/cindys
# mkdir test2.dir
# cd test2.dir
# touch file.2
# ls -V file.2
-rw-r--r--   1 root     root           0 Jun 17 10:40 file.2
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Beispiel 8–12 Vererbung der Zugriffssteuerungsliste mit der Eigenschaft `aclinherit`, die auf `passthrough-x` gesetzt ist

Ist die Eigenschaft aclinherit auf passthrough-x gesetzt, werden Dateien mit der Ausführungsberechtigung (x) für owner@, group@ oder everyone@ erstellt, allerdings nur, wenn die Ausführungsberechtigung im Dateierstellungsmodus und in einem vererbbaren Zugriffssteuerungseintrag, der den Modus betrifft, eingestellt ist.

Das folgende Beispiel zeigt, wie die Ausführungsberechtigung durch Setzen der Eigenschaft aclinherit auf passthrough-x vererbt wird.

# zfs set aclinherit=passthrough-x tank/cindys

Die folgende Zugriffssteuerungsliste ist auf /tank/cindys/test1.dir gesetzt, um ausführbare Zugriffssteuerungslisten-Vererbung für Dateien für owner@, group@ und everyone@ bereitzustellen.

# chmod A=owner@:rwxpcCosRrWaAdD:fd:allow,group@:rwxp:fd:allow,everyone@::fd:allow test1.dir
# ls -Vd test1.dir
drwxrwx---+  2 root     root           2 Jun 17 10:41 test1.dir
            owner@:rwxpdDaARWcCos:fd----:allow
            group@:rwxp----------:fd----:allow
         everyone@:--------------:fd----:allow

Es wird eine Datei (file1) mit den angeforderten Zugriffsrechten 0666 erstellt. Die resultierenden Zugriffsrechte sind 0660. Die Ausführungsberechtigung wurde nicht vererbt, weil der Erstellungsmodus dies nicht fordert.

# touch test1.dir/file1
# ls -V test1.dir/file1
-rw-rw----+  1 root     root           0 Jun 17 10:42 test1.dir/file1
            owner@:rw-pdDaARWcCos:------:allow
            group@:rw-p----------:------:allow
         everyone@:--------------:------:allow

Als Nächstes wird das Executable t unter Verwendung des Compilers cc im Verzeichnis testdir erstellt.

# cc -o t t.c
# ls -V t
-rwxrwx---+  1 root     root        7396 Jun 17 10:50 t
                 owner@:rwxpdDaARWcCos:------:allow
                 group@:rwxp----------:------:allow
              everyone@:--------------:------:allow

Die resultierenden Zugriffsrechte sind 0770, weil cc die Zugriffsrechte 0777 gefordert hat, weswegen die Ausführungsberechtigung von den Einträgen owner@, group@ und everyone@ geerbt wurde.