Neues Solaris-Modell für Zugriffskontrolllisten

Frühere Versionen des Betriebssystems Solaris unterstützten eine auf der POSIX-Spezifikation beruhende Implementierung von Zugriffskontrolllisten. POSIX-basierte Zugriffskontrolllisten 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 Zugriffskontrolllisten 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 Zugriffskontrolllisten bietet eine reichhaltigere Semantik, die auf NT-basierten Zugriffskontrolllisten beruht.

Die Hauptunterschiede des neuen Zugriffskontrolllistenmodells bestehen in Folgendem:

Basiert auf der NFSv4-Spezifikation und ähnelt NT-Zugriffskontrolllistenmodellen,
enthält einen feiner abstimmbaren Satz an Zugriffsrechten, Weitere Informationen finden Sie in Tabelle 8-2.
wird mit den Befehlen chmod und ls anstatt setfacl und getfacl eingestellt und angezeigt,
enthält eine reichhaltigere Vererbungssemantik, um festlegen zu können, wie Zugriffsrechte von über- und untergeordneten Verzeichnissen geregelt werden, usw. Weitere Informationen dazu finden Sie in Vererbung von Zugriffskontrolllisten.

Beide Zugriffskontrolllistenmodelle bieten eine feiner abstimmbare Kontrolle von Zugriffsrechten als die Standardzugriffsrechte. Wie bei POSIX-basierten Zugriffskontrolllisten bestehen auch die neuen Zugriffskontrolllisten aus mehreren Zugriffskontrolleinträgen.

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

Die Konvertierung zwischen NFSv4-basierten und POSIX-basierten Zugriffskontrolllisten 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 Zugriffskontrolllisten in die entsprechenden NFSv4-basierten Zugriffskontrolllisten konvertiert, damit UFS-Dateien mit Zugriffskontrolllisten in ein ZFS-Dateisystem transferiert werden können.
Einige NFSv4-basierte Zugriffskontrolllisten werden in POSIX-basierte Zugriffskontrolllisten konvertiert. Wenn eine NFSv4–basierte Zugriffskontrollliste nicht in eine POSIX-basierte Zugriffskontrollliste konvertiert werden kann, wird in etwas die folgende Meldung angezeigt:
```
# 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 Zugriffskontrollliste (tar -p bzw. cpio -P) erstellen, gehen beim Extrahieren des Archivs auf einem System, auf dem eine frühere Solaris-Version installiert ist, die Zugriffskontrolllisten verloren.

Alle Dateien werden mit den ordnungsgemäßen Dateimodi extrahiert, aber die Zugriffskontrolllisten werden ignoriert.
Der Befehl ufsrestore ermöglicht es, Daten in einem ZFS-Dateisystem wiederherzustellen. Wenn die Originaldaten POSIX-basierte Zugriffskontrolllisten enthalten, werden diese in NFSv4-basierte Zugriffskontrolllisten konvertiert.
Wenn Sie versuchen, eine NFSv4-basierte Zugriffskontrollliste an einer UFS-Datei zu setzen, wird eine Meldung wie die folgende angezeigt:
```
chmod: ERROR: ACL type's are different
```
Wenn Sie versuchen, eine POSIX-basierte Zugriffskontrollliste an einer ZFS-Datei zu setzen, 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 Zugriffskontrolllisten und Backup-Software finden Sie unter Sichern von ZFS-Daten mit anderen Softwarepaketen zur Erstellung von Sicherungskopien.

Syntaxbeschreibungen zum Setzen von Zugriffskontrolllisten

Es gibt zwei grundlegende Zugriffskontrolllistenformate:

Syntax zum Setzen gewöhnlicher Zugriffskontrolllisten

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 Zugriffskontrolllisten

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 Zugriffskontrolllisten-Eintragstyp für die gewöhnliche Zugriffskontrolllistensyntax. Eine Beschreibung der Zugriffskontrolllisten-Eintragstypen finden Sie in Tabelle 8-1.
user oder group:Zugriffskontrolllisteneintrags-ID=Benutzername oder Gruppenname: Der Zugriffskontrolllisten-Eintragstyp für die explizite Zugriffskontrolllistensyntax. Der Zugriffskontrolllisten-Eintragstyp "user" bzw. "group" muss auch die Zugriffskontrolllisteneintrags-ID, den Benutzernamen bzw. Gruppennamen enthalten. Eine Beschreibung der Zugriffskontrolllisten-Eintragstypen finden Sie in Tabelle 8-1.
Zugriffsrechte/.../: Die Zugriffsrechte, die gewährt bzw. verweigert werden. Eine Beschreibung von Zugriffsrechten für Zugriffskontrolllisten finden Sie in Tabelle 8-2.
Vererbungsflags: Eine optionale Liste von Vererbungsflags von Zugriffskontrolllisten. Eine Beschreibung der Vererbungsflags von Zugriffskontrolllisten finden Sie in Tabelle 8-3.
deny | allow: Legt fest, ob Zugriffsrechte gewährt oder verweigert werden.

Im folgenden Beispiel ist keine Zugriffskontrolllisteneintrags-ID für owner@, group@ oder everyone@ vorhanden.

group@:write_data/append_data/execute:deny

Das folgende Beispiel enthält eine Zugriffskontrolllisteneintrags-ID, da ein spezifischer Benutzer (Zugriffskontrolllisten-Eintragstyp) in der Zugriffskontrollliste enthalten ist.

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

Ein Zugriffskontrolllisteneintrag 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 Zugriffskontrolllisteneintrag in der größeren Zugriffskontrollliste, 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 Zugriffskontrollliste 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

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

Tabelle 8-1 Zugriffskontrolllisten- Eintragstypen

Zugriffskontrolllisten- 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 Zugriffskontrolllisteneinträge entsprechen.
`user`	Das Zugriffsrecht, das einem zusätzlichen (und durch den Benutzernamen anzugebenden) Benutzer des Objekts gewährt wird. Muss die Zugriffskontrolllisteneintrags-ID enthalten, die wiederum den betreffenden `Benutzernamen` oder die `Benutzer-ID` enthält. Wenn es sich bei diesem Wert um keine gültige numerische Benutzer-ID oder keinen `Benutzername` handelt, ist der Zugriffskontrolllisten-Eintragstyp ungültig.
`group`	Das Zugriffsrecht, das einer zusätzlichen (und durch den Gruppennamen anzugebenden) Benutzergruppe des Objekts gewährt wird. Muss die Zugriffskontrolllisteneintrags-ID enthalten, die wiederum den betreffenden `Gruppennamen` oder die `Gruppen-ID` enthält. Wenn es sich bei diesem Wert um keine gültige numerische Gruppen-ID oder keinen `Gruppenname` handelt, ist der Zugriffskontrolllisten-Eintragstyp ungültig.

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

Tabelle 8-2 Zugriffskontrolllisten-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 bzw. 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 Zugriffskontrollliste (`ls`).
read_attributes	a	Berechtigung zum Lesen grundlegender (nicht zu Zugriffskontrolllisten gehörender) Attribute einer Datei. Grundlegende Attribute sind Attribute auf der stat-Ebene. Durch Setzen dieses Zugriffsmaskenbits kann ein Objekt `ls`(1) und `stat`(2) ausführen.
read_data	r	Berechtigung zum Lesen des Inhalts einer 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	W	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	A	Berechtigung zum Setzen der Zeitmarken einer Datei bzw. eines Verzeichnisses auf einen beliebigen Wert.
write_acl	C	Berechtigung zum Schreiben bzw. Ändern der Zugriffsteuerungliste 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 Zugriffskontrolllisten

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

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

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

Tabelle 8-3 Vererbungsflags von Zugriffskontrolllisten

Vererbungsflag	Kurzform	Beschreibung
`file_inherit`	`f`	Die Zugriffskontrollliste wird nur vom übergeordneten Verzeichnis an die Dateien des betreffenden Verzeichnisses vererbt.
`dir_inherit`	`d`	Die Zugriffskontrollliste wird nur vom übergeordneten Verzeichnis an die untergeordneten Verzeichnisse des betreffenden Verzeichnisses vererbt.
`inherit_only`	`i`	Die Zugriffskontrollliste 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 Zugriffskontrollliste 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 Zugriffskontrolllisten festlegen. Weitere Informationen finden Sie im folgenden Abschnitt.

Eigenschaften von Zugriffskontrolllisten (`aclinherit`)

Das ZFS-Dateisystem umfasst die Eigenschaft aclinherit zur Bestimmung des Verhaltens der Vererbung von Zugriffskontrolllisten. Folgende Werte stehen zur Verfügung:

discard – Für neu erstellte Objekte werden beim Erstellen von Dateien und Verzeichnissen keine Zugriffskontrolllisteneinträge vererbt. Die Zugriffskontrollliste der Datei bzw. des Verzeichnisses entspricht dem Zugriffsrechtsmodus dieser Datei bzw. dieses Verzeichnisses.
noallow – Bei neuen Objekten werden nur vererbbare Zugriffskontrolllisteneinträge mit Zugriffstyp deny vererbt.
restricted – Für neu erstellte Objekte werden beim Vererben von Zugriffskontrolllisteneinträgen die Zugriffsrechte write_owner und write_acl entfernt.
passthrough – Ist der Eigenschaftswert auf passthrough gesetzt, werden die Dateien mit einem durch die vererbbaren Zugriffskontrolleinträge festgelegten Modus erstellt. Wenn keine den Modus betreffenden vererbbaren Zugriffskontrolleinträge vorhanden sind, wird ein mit der Forderung der Anwendung vereinbarter Modus gesetzt.
passthrough-x – 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 eines vererbbaren Zugriffskontrolleintrags festgelegt wurde, die sich auf den Modus auswirkt.

Der Standardmodus für aclinherit ist restricted.

Navigationslinks �berspringen
Druckansicht beenden
	Oracle Solaris ZFS-Administrationshandbuch