| SUSE LINUX – Administrationshandbuch Anhang B. Access Control Lists unter Linux / B.3. Umgang mit ACLs | ||||
|---|---|---|---|---|
 | B.2. Definitionen | B.4. Unterstützung in Anwendungen |  | |
| SUSE LINUX – Administrationshandbuch Anhang B. Access Control Lists unter Linux / B.3. Umgang mit ACLs | ||||
|---|---|---|---|---|
| B.2. Definitionen | B.4. Unterstützung in Anwendungen | | |
Im folgenden Abschnitt lernen Sie den Grundaufbau einer ACL und deren verschiedene Ausprägungen kennen. Der Zusammenhang zwischen ACLs und dem traditionellen Rechtekonzept im Linux-Dateisystem wird anhand mehrerer Grafiken kurz erläutert. An zwei Beispielen lernen Sie, selbst ACLs zu erstellen und deren korrekte Syntax zu beachten. Zuletzt erfahren Sie, nach welchem Muster ACLs vom Betriebssystem ausgewertet werden.
ACLs werden grundsätzlich in zwei Klassen eingeteilt. Eine minimale ACL besteht ausschließlich aus den Einträgen vom Typ owner (Besitzer), owning group (Besitzergruppe) und other (Andere), und entspricht den herkömmlichen Berechtigungsbits für Dateien und Verzeichnisse. Eine erweiterte (engl. extended) ACL geht über dieses Konzept hinaus. Sie muss einen mask (Maske) Eintrag enthalten und darf mehrere Einträge des Typs named user (namentlich gekennzeichneter Benutzer) und named group (namentlich gekennzeichnete Gruppe) enthalten. Tabelle B.1. “Überblick: Typen von ACL-Einträgen” fasst die verschiedenen verfügbaren Typen von ACL-Einträgen zusammen.
Tabelle B.1. Überblick: Typen von ACL-Einträgen
| Typ | Textform |
|---|---|
| owner | user::rwx |
| named user | user:name:rwx |
| owning group | group::rwx |
| named group | group:name:rwx |
| mask | mask::rwx |
| other | other::rwx |
In den Einträgen owner und other festgelegte Rechte sind immer wirksam. Vom mask Eintrag abgesehen, können alle übrigen Einträge (named user, owning group und named group) entweder wirksam oder maskiert werden. Sind Rechte sowohl in einem der oben genannten Einträge als auch in der Maske vorhanden, werden sie wirksam. Rechte, die nur in der Maske oder nur im eigentlichen Eintrag vorhanden sind, sind nicht wirksam. Das nachfolgende Beispiel verdeutlicht diesen Mechanismus (siehe Tabelle B.2. “Maskierung von Zugriffsrechten”):
Die beiden Abbildungen illustrieren die beiden auftretenden Fälle einer minimalen und einer erweiterten ACL (siehe Abb. B.1. “Minimale ACL: ACL-Einträge vs. Berechtigungsbits” und B.2. “Erweiterte ACL: ACL-Einträge vs. Berechtigungsbits”). Die Abbildungen gliedern sich in drei Blöcke. Links die Typangaben der ACL-Einträge, in der Mitte eine beispielhafte ACL und rechts die entsprechenden Berechtigungsbits, wie sie auch ls -l anzeigt.
In beiden Fällen werden die owner class Berechtigungen dem owner ACL-Eintrag zugeordnet. Die Zuordnung der other class Berechtigungen zum entsprechenden ACL-Eintrag ist ebenfalls konstant. Die Zuordnung der group class Berechtigungen variiert:
Im Fall einer minimalen ACL — ohne mask Eintrag — werden die group class Berechtigungen dem owning group ACL-Eintrag zugeordnet (siehe Abb. B.1. “Minimale ACL: ACL-Einträge vs. Berechtigungsbits”).
Im Fall einer erweiterten ACL — mit mask Eintrag — werden die group class Berechtigungen dem mask Eintrag zugeordnet (siehe Abb. B.2. “Erweiterte ACL: ACL-Einträge vs. Berechtigungsbits”).
Durch diese Art der Zuordnung ist die reibungslose Interaktion von Anwendungen mit und ohne ACL-Unterstützung gewährleistet. Die Zugriffsrechte, die mittels der Berechtigungsbits festgelegt wurden, sind die Obergrenze für alle anderen „Feineinstellungen“, die per ACL gemacht werden. Alle Rechte, die hier nicht widergespiegelt sind, wurden entweder in der ACL nicht gesetzt oder sind nicht effektiv. Werden Berechtigungsbits geändert, spiegelt sich dies in der ACL wider und umgekehrt.
In drei Schritten werden Sie anhand folgendem Beispiel den Umgang mit einer Access ACL lernen:
Anlegen eines Dateisystemobjekts (hier eines Verzeichnisses)
Änderungen an der ACL
Einsatz von Masken
Bevor Sie das Verzeichnis anlegen, können Sie mittels des umask Befehls festlegen, welche Zugriffsrechte gleich bei der Erstellung maskiert werden sollen:
umask 027
umask 027 beschränkt die Rechte der einzelnen Benutzergruppen folgendermaßen: der Besitzer der Datei behält sämtliche Rechte (0), die Besitzergruppe darf nicht schreibend auf die Datei zugreifen (2) und alle anderen Benutzer erhalten keinerlei Zugriff (7). Die Zahlen sind als Bitmaske zu lesen. Details zu umask entnehmen Sie der entsprechenden Manualpage (man umask).
mkdir mydir
Das Verzeichnis mydir ist angelegt und hat die durch die umask festgelegten Rechte erhalten. Mit
ls -dl mydir drwxr-x--- ... tux projekt3 ... mydir
überprüfen Sie, ob alle Rechte korrekt vergeben wurden.
Nachdem Sie sich über den Ausgangszustand der ACL informiert haben, fügen Sie ihr jeweils einen neuen Benutzer- und Gruppen-Eintrag hinzu.
getfacl mydir # file: mydir # owner: tux # group: projekt3 user::rwx group::r-x other::---
Die Ausgabe von getfacl spiegelt exakt die unter Abschnitt B.3.2. “ACL-Einträge und Berechtigungsbits” beschriebene Zuordnung von Berechtigungsbits und ACL-Einträgen wider. Die ersten drei Zeilen der Ausgabe nennen Namen, Eigentümer und zugehörige Gruppe des Verzeichnisses. Die drei nächsten Zeilen enthalten die drei ACL-Einträge owner, owning group und other. Insgesamt liefert Ihnen der getfacl Befehl im Fall dieser einfachsten („minimalen“) ACL keine Information, die Sie mittels ls nicht auch erhalten hätten.
Ihr erster Eingriff in die ACL besteht darin, einem zusätzlichen Benutzer jane und einer zusätzlichen Gruppen djungle Lese-, Schreib- und Ausführrechte zu gewähren.
setfacl -m user:jane:rwx,group:djungle:rwx mydir
Die Option -m weist setfacl an, die bestehende ACL zu modifizieren. Das nachfolgende Argument gibt an, welche ACL-Einträge geändert werden (mehrere werden durch Kommata voneinander getrennt). Abschließend geben Sie den Namen des Verzeichnisses an, für das diese Änderungen gelten sollen.
Die resultierende ACL geben Sie wieder mit getfacl aus.
# file: mydir # owner: tux # group: projekt3 user::rwx user:jane:rwx group::r-x group:djungle:rwx mask::rwx other::---
Zusätzlich zu den von Ihnen initiierten Einträgen für den Benutzer jane und die Gruppe djungle wurde ein mask Eintrag erzeugt. Dieser mask Eintrag wird automatisch gesetzt, um alle Einträge in der group class auf einen gemeinsamen Nenner zu bringen. Außerdem passt setfacl bestehende mask Einträge an von Ihnen geänderte Einstellungen automatisch an, so Sie das nicht mit -n deaktivieren. mask legt die maximal wirksamen Zugriffsrechte für alle Einträge innerhalb der group class fest. Dies beinhaltet: named user, named group und owning group. Die group class Berechtigungsbits, die ein ls -dl mydir ausgeben würde, entsprechen jetzt dem mask-Eintrag.
ls -dl mydir
drwxrwx---+ ... tux projekt3 ... mydir
Es erscheint in der ersten Spalte der Ausgabe ein +, das auf eine erweiterte ACL hinweist.
Gemäß der Ausgabe des ls Kommandos beinhalten die Rechte für den mask Eintrag auch Schreibzugriff. Traditionell würden diese Berechtigungsbits auch darauf hinweisen, dass die owning group (hier: projekt3) ebenfalls Schreibzugriff auf das Verzeichnis mydir hätte. Allerdings sind die wirklich wirksamen Zugriffsrechte für die owning group als die Schnittmenge aus den für owning group und mask gesetzten Rechten definiert; also in unserem Beispiel r-x (siehe Tabelle B.2. “Maskierung von Zugriffsrechten”). Es hat sich auch nach Hinzufügen der ACL-Einträge nichts an den Rechten der owning group geändert.
Verändern können Sie den mask Eintrag mittels setfacl oder chmod.
chmod g-w mydir ls -dl mydir drwxr-x---+ ... tux projekt3 ... mydir
getfacl mydir # file: mydir # owner: tux # group: projekt3 user::rwx user:jane:rwx # effective: r-x group::r-x group:djungle:rwx # effective: r-x mask::r-x other::---
Nachdem Sie per chmod die group class Bits um den Schreibzugriff verringert haben, liefert Ihnen schon die Ausgabe des ls Kommandos den Hinweis darauf, dass die mask Bits über chmod entsprechend angepasst wurden. Man erkennt, dass nur der Besitzer Schreibberechtigung im Verzeichnis mydir hat. Noch deutlicher wird dies an der Ausgabe von getfacl. getfacl fügt für alle Einträge Kommentare hinzu, deren tatsächlich wirksame Berechtigungsbits nicht mit den ursprünglich gesetzten übereinstimmen, weil sie vom mask Eintrag herausgefiltert werden. Sie können den Ausgangszustand mit dem entsprechenden chmod Kommando wiederherstellen:
chmod g+w mydir ls -dl mydir drwxrwx---+ ... tux projekt3 ... mydir
getfacl mydir
# file: mydir
# owner: tux
# group: projekt3
user::rwx
user:jane:rwx
group::r-x
group:djungle:rwx
mask::rwx
other::---
Verzeichnisse können mit einer besonderen Art von ACLs versehen werden; einer Default ACL. Diese Default ACL legt fest, welche Zugriffsrechte Unterobjekte dieses Verzeichnisses zum Zeitpunkt ihrer Erstellung erben. Eine Default ACL wirkt sich auf Unterverzeichnisse ebenso wie auf Dateien aus.
Die Zugriffsrechte in einer Default ACL werden an Dateien und Unterverzeichnisse unterschiedlich vererbt:
Ein Unterverzeichnis erbt die Default ACL des übergeordneten Verzeichnisses sowohl als seine eigene Default ACL als auch als Access ACL.
Eine Datei erbt die Default ACL als ihre eigene Access ACL.
Alle Systemaufrufe (engl. system calls), die Dateisystemobjekte anlegen, verwenden einen mode Parameter. Der mode Parameter legt die Zugriffsrechte auf das neu anzulegende Dateisystemobjekt fest:
Hat das übergeordnete Verzeichnis keine Default ACL, ergeben sich die Berechtigungen aus den im mode-Parameter angegebenen Berechtigungen, von denen die in der umask gesetzten Rechte abgezogen werden.
Existiert eine Default ACL für das übergeordnete Verzeichnis, werden die Berechtigungsbits entsprechend der Schnittmenge aus dem Wert des mode Parameters und den in der Default ACL festgelegten Berechtigungen zusammengesetzt und dem Objekt zugewiesen. Die umask wird in diesem Fall nicht beachtet.
Die drei folgenden Beispiele führen Sie an die wichtigsten Operationen an Verzeichnissen und Default ACLs heran:
Anlegen einer Default ACL für ein bestehendes Verzeichnis
Anlegen eines Unterverzeichnisses in einem Verzeichnis mit Default ACL
Anlegen einer Datei in einem Verzeichnis mit Default ACL
Sie fügen dem schon existierenden Verzeichnis mydir eine Default ACL hinzu:
setfacl -d -m group:djungle:r-x mydir
Die -d Option des setfacl Kommandos weist setfacl an, die folgenden Modifikationen (Option -m) auf der Default ACL vorzunehmen.
Sehen Sie sich das Ergebnis dieses Befehls genauer an:
getfacl mydir # file: mydir # owner: tux # group: projekt3 user::rwx user:jane:rwx group::r-x group:djungle:rwx mask::rwx other::--- default:user::rwx default:group::r-x default:group:djungle:r-x default:mask::r-x default:other::---
getfacl liefert sowohl die Access ACL als auch die Default ACL zurück. Alle Zeilen, die mit default beginnen, bilden zusammen die Default ACL. Obwohl Sie dem setfacl Befehl lediglich einen Eintrag für die Gruppe djungle in die Default ACL mitgegeben hatten, hat setfacl automatisch alle anderen Einträge aus der Access ACL kopiert, um so eine gültige Default ACL zu bilden. Default ACLs haben keinen direkten Einfluss auf die Zugriffsberechtigungen und wirken sich nur beim Erzeugen von Dateisystemobjekten aus. Beim Vererben wird nur die Default ACL des übergeordneten Verzeichnisses beachtet.
Legen Sie im nächsten Beispiel mit mkdir ein Unterverzeichnis in mydir an, welches die Default ACL „erben“ wird.
mkdir mydir/mysubdir getfacl mydir/mysubdir # file: mydir/mysubdir # owner: tux # group: projekt3 user::rwx group::r-x group:djungle:r-x mask::r-x other::--- default:user::rwx default:group::r-x default:group:djungle:r-x default:mask::r-x default:other::---
Wie erwartet, hat das neu angelegte Unterverzeichnis mysubdir die Rechte aus der Default ACL des übergeordneten Verzeichnisses. Die Access ACL von mysubdir ist ein exaktes Abbild der Default ACL von mydir, ebenso die Default ACL, die dieses Verzeichnis wiederum an seine Unterobjekte weitervererben wird.
Legen Sie im mydir Verzeichnis mit touch eine Datei an:
touch mydir/myfile ls -l mydir/myfile -rw-r-----+ ... tux projekt3 ... mydir/myfile
getfacl mydir/myfile # file: mydir/myfile # owner: tux # group: projekt3 user::rw- group::r-x # effective:r-- group:djungle:r-x # effective:r-- mask::r-- other::---
Wichtig an diesem Beispiel: touch übergibt mode mit dem Wert von 0666, das bedeutet, dass neue Dateien mit Lese- und Schreibrechten für alle Benutzerklassen angelegt werden, so nicht entweder per umask oder Default ACL andere Beschränkungen existieren (siehe Abschnitt B.3.4.1. “Auswirkungen einer Default ACL”).
Am konkreten Beispiel heißt dies, dass alle Zugriffsrechte, die nicht im mode Wert enthalten sind, aus den entsprechenden ACL-Einträgen entfernt werden: Aus dem ACL-Eintrag der group class wurden keine Berechtigungen entfernt, allerdings wurde der mask Eintrag dahingehend angepasst, dass nicht per mode gesetzte Berechtigungsbits maskiert werden.
Auf diese Weise ist sichergestellt, dass zum Beispiel Compiler reibungslos mit ACLs interagieren können. Sie können Dateien mit beschränkten Zugriffsrechten anlegen und diese anschließend als ausführbar markieren. Über den mask Mechanismus ist gewährleistet, dass die richtigen Benutzer und Gruppen schließlich die Datei ausführen können.
Nachdem Sie den Umgang mit den wichtigsten Tools zur ACL-Konfiguration bereits verstanden haben, werden Sie im Folgenden kurz an den Auswertungsalgorithmus herangeführt, den jeder Prozess oder jede Anwendung durchlaufen muss, bevor ihm Zugriff auf ein ACL-geschütztes Dateisystemobjekt gewährt werden kann.
Grundsätzlich werden die ACL-Einträge in folgender Reihenfolge untersucht: owner, named user, owning group oder named group und other. Über den Eintrag, der am besten auf den Prozess passt, wird schließlich der Zugang geregelt.
Komplizierter werden die Verhältnisse, wenn ein Prozess zu mehr als einer Gruppe gehört, also potentiell auch mehrere group Einträge passen könnten. Aus den passenden Einträgen mit den erforderlichen Rechten wird ein beliebiger ausgesucht. Für das Endresultat „Zugriff gewährt“ ist es natürlich unerheblich, welcher dieser Einträge den Ausschlag gegeben hat. Enthält keiner der passenden group Einträge die korrekten Rechten, gibt wiederum ein beliebiger von ihnen den Ausschlag für das Endresultat Zugriff verweigert.
