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:
Setzen und Anzeigen von Zugriffssteuerungslisten an ZFS-Dateien im ausführlichen Format
Setzen und Anzeigen von Zugriffssteuerungslisten an ZFS-Dateien im Kompaktformat
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.
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
Der Zugriffssteuerungslisten-Eintragstyp für die gewöhnliche Zugriffssteuerungslistensyntax. Eine Beschreibung der Zugriffssteuerungslisten-Eintragstypen finden Sie in Tabelle 8–1.
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.
Die Zugriffsrechte, die gewährt bzw. verweigert werden. Eine Beschreibung von Zugriffsrechten für Zugriffssteuerungslisten finden Sie in Tabelle 8–2.
Eine optionale Liste von Vererbungsflags von Zugriffssteuerungslisten. Eine Beschreibung der Vererbungsflags von Zugriffssteuerungslisten finden Sie in Tabelle 8–3.
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. |
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.
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.
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:
Dem Eigentümer wird das Ausführen der Datei verweigert (execute:deny).
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).
Der Gruppe wird das Ausführen der Datei verweigert (write_data/append_data/execute:deny).
Der Gruppe wird die Berechtigung zum Lesen der Datei gewährt (read_data:allow).
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 ).
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:
Die Verweigerungsliste für den Eigentümer ist leer (::deny).
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).
Die Gruppe kann den Verzeichnisinhalt weder erweitern noch ändern ( add_file/write_data/add_subdirectory/append_data:deny).
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 ).
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).
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.
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.
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 |
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 |
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 |
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 |
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.
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 |
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 |
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.
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 |
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 |
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:
Dem Eigentümer wird das Ausführen der Datei verweigert (x= execute).
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).
Der Gruppe werden Änderungs- und Ausführungsberechtigung für die Datei verweigert (write_data, p= append_data und x=execute).
Der Gruppe wird die Berechtigung zum Lesen der Datei gewährt (r= read_data).
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).
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.
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 |
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 |
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.