1. Oracle Solaris ZFS-Dateisystem (Einführung)
2. Erste Schritte mit Oracle Solaris ZFS
3. Unterschiede zwischen Oracle Solaris ZFS und herkömmlichen Dateisystemen
4. Verwalten von Oracle Solaris ZFS-Speicher-Pools
5. Installieren und Booten eines Oracle Solaris ZFS-Root-Dateisystems
6. Verwalten von Oracle Solaris ZFS-Dateisystemen
7. Arbeiten mit Oracle Solaris ZFS-Snapshots und -Klonen
8. Schützen von Oracle Solaris ZFS-Dateien mit Zugriffskontrolllisten und Attributen
Neues Solaris-Modell für Zugriffskontrolllisten
Syntaxbeschreibungen zum Setzen von Zugriffskontrolllisten
Setzen von Zugriffskontrolllisten an ZFS-Dateien
Setzen und Anzeigen von Zugriffskontrolllisten an ZFS-Dateien im ausführlichen Format
Festlegen der Vererbung von Zugriffskontrolllisten an ZFS-Dateien im ausführlichen Format
Setzen und Anzeigen von Zugriffskontrolllisten an ZFS-Dateien im Kompaktformat
9. Delegierte Oracle Solaris ZFS-Administration
10. Fortgeschrittene Oracle Solaris ZFS-Themen
11. Problembehebung und Pool-Wiederherstellung in Oracle Solaris ZFS
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.
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
Der Zugriffskontrolllisten-Eintragstyp für die gewöhnliche Zugriffskontrolllistensyntax. Eine Beschreibung der Zugriffskontrolllisten-Eintragstypen finden Sie in Tabelle 8-1.
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.
Die Zugriffsrechte, die gewährt bzw. verweigert werden. Eine Beschreibung von Zugriffsrechten für Zugriffskontrolllisten finden Sie in Tabelle 8-2.
Eine optionale Liste von Vererbungsflags von Zugriffskontrolllisten. Eine Beschreibung der Vererbungsflags von Zugriffskontrolllisten finden Sie in Tabelle 8-3.
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
|
In der folgenden Tabelle sind die Zugriffsrechte für Zugriffskontrolllisten beschrieben.
Tabelle 8-2 Zugriffskontrolllisten-Zugriffsrechte
|
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
|
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.
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.