Tabelle 35.1, „Überblick: Typen von ACL-Einträgen“ gibt einen Überblick über die sechs verschiedenen Typen von ACL-Einträgen. Jeder davon legt Rechte für einen Benutzer oder eine Gruppe von Benutzern fest. Der Eintrag owner definiert die Rechte für den Besitzer der Datei oder des Verzeichnisses. Der Eintrag owning group definiert die Rechte für die Besitzergruppe, der das Dateisystemobjekt gehört. Als Systemadministrator kann man den Besitzer und die Besitzergruppe mit den Befehlen chown bzw. chgrp ändern, wonach die sich die Einträge für Besitzer und Besitzergruppe entsprechend ändern. Ein Eintrag für einen named user (namentlich gekennzeichneten Benutzer) definiert die Rechte nur für diesen explizit genannten Benutzer, wie er im entsprechenden Bezeichnerfeld angegeben ist (d.h. das mittlere Feld nach dem Schema von Tabelle 35.1, „Überblick: Typen von ACL-Einträgen“). Darüber hinaus kann ein Eintrag für eine named group (namentlich gekennzeichnete Gruppe) die Rechte für eine explizit genannte Gruppe definieren, wie sie im Bezeichnerfeld angegeben wird. Bei den Einträgen vom Typ named user und named group darf also das Bezeichnerfeld nicht leer bleiben. Schließlich definiert der Eintrag other die Rechte aller übrigen Benutzer.
Der zusätzliche Eintrag mask (Maske) begrenzt die Rechte, die unter den Einträgen named user, named group und owning group angeben sind. Hierbei wird definiert, welche jener Rechte tatsächlich wirksam und welche maskiert (latent vorhanden, verborgen) sind. Solche Rechte, die sowohl in einem der oben genannten Einträge als auch in der Maske vorhanden sind, werden wirksam. Solche Rechte dagegen, die nur in der Maske oder nur im eigentlichen Eintrag vorkommen, sind nicht wirksam, sie werden also verweigert. Die mit den Einträgen owner und other definierten Rechte sind immer wirksam. Das Beispiel in Tabelle 35.2, „Maskierung von Zugriffsrechten“ verdeutlicht diesen Mechanismus.
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 damit den herkömmlichen Berechtigungsbits für Dateien und Verzeichnisse. Eine erweiterte (engl. extended) ACL geht über dieses Konzept hinaus. Sie muss einen Eintrag vom Typ mask (Maske) enthalten und darf mehrere Einträge des Typs named user und named group enthalten.
Tabelle 35.1. Überblick: Typen von ACL-Einträgen
Typ | Textform |
|---|---|
owner |
|
named user |
|
owning group |
|
named group |
|
mask |
|
other |
|
Tabelle 35.2. Maskierung von Zugriffsrechten
Typ | Textform | Rechte |
|---|---|---|
named user |
|
|
mask |
|
|
Wirksame Berechtigungen: |
|
Abbildung 35.1, „Minimale ACL: ACL-Einträge vs. Berechtigungsbits“ und Abbildung 35.2, „Erweiterte ACL: ACL-Einträge vs. Berechtigungsbits“
illustrieren die beiden auftretenden Fälle einer minimalen und einer
erweiterten ACL. Die Abbildungen gliedern sich in drei Blöcke. Links die
Angaben zum Typ der ACL-Einträge, in der Mitte eine Beispiel-ACL und rechts
die entsprechenden Berechtigungsbits, wie sie auch ls
-l anzeigt. In beiden Fällen werden die Berechtigungen der
owner class dem ACL-Eintrag owner
zugeordnet. Die Berechtigungen der other class werden
ebenfalls dem entsprechenden ACL-Eintrag zugeordnet. Die Zuordnung der
Berechtigungen der group class ist jedoch in beiden
Fällen unterschiedlich.
Im Fall einer minimalen ACL — ohne mask-Eintrag — werden die Berechtigungen der group class Berechtigungen dem ACL-Eintrag owning group zugeordnet. Diese Variante wird in Abbildung 35.1, „Minimale ACL: ACL-Einträge vs. Berechtigungsbits“ dargestellt. Im Fall einer erweiterten ACL — mit mask-Eintrag — werden die Berechtigungen der group class dem mask-Eintrag zugeordnet, wie in Abbildung 35.2, „Erweiterte ACL: ACL-Einträge vs. Berechtigungsbits“ dargestellt.
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. Werden Berechtigungsbits geändert, spiegelt sich dies in der ACL wider und umgekehrt.
Das folgende Beispiel erläutert die Handhabung von Access ACLs:
Bevor Sie ein Verzeichnis anlegen, können Sie mittels des
umask-Befehls festlegen, welche Zugriffsrechte gleich bei
der Erstellung eines Dateisystemobjekts maskiert werden sollen. Der Befehl
umask 027 beispielsweise legt die Vorgabe für die
Benutzerrechte folgendermaßen fest: 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 Maskierung der
Berechtigungsbits durch den umask-Befehl bedeutet, dass
die angegebenen Bits subtrahiert werden. Details hierzu finden Sie in der
entsprechenden Manualpage (man umask).
Der Befehl mkdir mydir sollte nunmehr das Verzeichnis
mydir mit den Benutzerrechten anlegen, wie sie mit
umask vorgegeben wurden. Mittels ls -dl
mydir können Sie überprüfen, ob dies der Fall ist. Der
Befehl sollte eine Ausgabe der folgenden Art erzeugen:
drwxr-x--- ... tux project3 ... mydir
Mit dem Befehl getfacl mydir können Sie
sich jetzt über den Ausgangszustand der ACL informieren. Dies sollte eine
Ausgabe wie die folgende ergeben:
# file: mydir # owner: tux # group: project3 user::rwx group::r-x other::---
Die Ausgabe von getfacl spiegelt exakt die in Abschnitt 35.3.1, „ACL-Einträge und Berechtigungsbits“ beschriebene Zuordnung von Berechtigungsbits und ACL-Einträgen wider. Die ersten drei Zeilen der Ausgabe nennen Namen, Besitzer und zugehörige Gruppe des Verzeichnisses. Die drei nächsten Zeilen enthalten die drei ACL-Einträge owner, owning group und other. Tatsächlich liefert Ihnen der getfacl-Befehl im Fall dieser minimalen ACL keine Information, die Sie mittels ls nicht auch erhalten hätten.
Ändern Sie jetzt die ACL dahingehend, dass Sie einem zusätzlichen Benutzer
geeko und einer zusätzlichen Gruppe
mascots Lese-, Schreib- und Ausführungsrechte gewähren:
setfacl -m user:geeko:rwx,group:mascots:rwx mydir
Die Option -m bewirkt, dass setfacl die
bestehende ACL modifiziert. Das darauf folgende Argument gibt an, welche
ACL-Einträge geändert werden sollen (mehrere werden durch Kommas voneinander
getrennt). Zum Schluss wird der Name des Verzeichnisses angegeben, für das
diese Änderungen gelten sollen. Die geänderte ACL können Sie sich wieder mit
getfacl anzeigen lassen:
# file: mydir # owner: tux # group: project3 user::rwx user:geeko:rwx group::r-x group:mascots:rwx mask::rwx other::---
Zusätzlich zu den von Ihnen veranlassten Einträgen für den Benutzer
geeko und die Gruppe mascots wurde ein
mask-Eintrag erzeugt. Dieser
mask-Eintrag wird automatisch erzeugt, damit alle
Benutzerrechte wirksam sind. Außerdem passt setfacl
bestehende mask-Einträge automatisch an alle
Veränderungen an — es sei denn, dass Sie dieses Verhalten mit
-n deaktivieren. Der mask-Eintrag
legt die maximal wirksamen Benutzerrechte für alle Einträge innerhalb der
group class fest, das heißt für die Einträge
named user, named group und
owning group. Die group
class-Berechtigungsbits, wie sie von ls
-dl mydir angezeigt werden, entsprechen jetzt dem
mask-Eintrag:
drwxrwx---+ ... tux project3 ... mydir
In der Ausgabe erscheint nun ein zusätzliches +, das auf
eine erweiterte ACL für dieses Verzeichnis hinweist.
Gemäß der Ausgabe des Kommandos ls beinhalten die Rechte
für den mask-Eintrag auch Schreibzugriff. Traditionell
würden diese Berechtigungsbits auch darauf hinweisen, dass die
owning group (also project3)
ebenfalls Schreibzugriff auf das Verzeichnis mydir
hätte. Allerdings sind die tatsächlich wirksamen Zugriffsrechte für die
owning group als die Schnittmenge aus den Rechten für
die owning group und den Rechten gemäß der
mask definiert — also in unserem Beispiel
r-x (siehe Tabelle 35.2, „Maskierung von Zugriffsrechten“). Es hat sich also
auch nach dem 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. Lautet der Befehl
zum Beispiel chmod g-w mydir, dann zeigt
ls -dl mydir folgende Benutzerrechte an:
drwxr-x---+ ... tux project3 ... mydir
Mit getfacl mydir ergibt sich nun
folgendes Bild:
# file: mydir # owner: tux # group: project3 user::rwx user:geeko:rwx # effective: r-x group::r-x group:mascots:rwx # effective: r-x mask::r-x other::---
Nachdem Sie per chmod die Bits der group
class um den Schreibzugriff verringert haben, liefert Ihnen
schon die Ausgabe des ls-Kommandos den Hinweis darauf,
dass die mask-Bits entsprechend angepasst wurden.
Jetzt hat wieder nur der Besitzer eine Schreibberechtigung im Verzeichnis
mydir. Noch deutlicher wird dies an der Ausgabe von
getfacl. Denn getfacl fügt für alle
Einträge Kommentare hinzu, deren wirksame Berechtigungsbits nicht mit den
ursprünglich gesetzten übereinstimmen, weil sie vom
mask-Eintrag herausgefiltert werden. Den
Ausgangszustand können Sie mit dem Befehl chmod g+w
mydir wiederherstellen.
Verzeichnisse können mit einer besonderen Art von ACLs versehen werden, einer Default ACL. Diese Default ACL legt fest, welche Zugriffsrechte die Objekte in diesem Verzeichnis 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. Dieser legt die
Zugriffsrechte für das neue 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:
Sie fügen dem schon existierenden Verzeichnis mydir
eine Default ACL hinzu:
setfacl -d -m group:mascots:r-x mydir
Die Option -d 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: project3 user::rwx user:geeko:rwx group::r-x group:mascots:rwx mask::rwx other::--- default:user::rwx default:group::r-x default:group:mascots: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
mascots 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: project3 user::rwx group::r-x group:mascots:r-x mask::r-x other::--- default:user::rwx default:group::r-x default:group:mascots: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 übernommen. 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 Verzeichnis mydir mit
touch eine Datei an, zum Beispiel mit touch
mydir/myfile. Die Ausgabe von ls
-l mydir/myfile ergibt dann Folgendes:
-rw-r-----+ ... tux project3 ... mydir/myfile
Die Ausgabe von getfacl mydir/myfile
ist wie folgt:
# file: mydir/myfile # owner: tux # group: project3 user::rw- group::r-x # effective:r-- group:mascots:r-x # effective:r-- mask::r-- other::---
Der Befehl touch übergibt beim Erzeugen neuer Dateien
den mode-Parameter mit dem Wert
0666, so dass diese Dateien mit Lese- und
Schreibrechten für alle Benutzerklassen angelegt werden, falls nicht
mittels umask oder Default ACL andere Beschränkungen
festgelegt wurden (siehe Abschnitt 35.3.3.1, „Auswirkungen einer Default ACL“).
Am konkreten Beispiel heißt dies, dass alle Zugriffsrechte, die nicht im
mode-Parameter 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 die
nicht im mode-Parameter enthaltenen Berechtigungsbits
maskiert werden.
Auf diese Weise ist sichergestellt, dass Anwendungen wie 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.
Bevor ein Prozess oder eine Anwendung auf ein Dateisystemobjekt zugreifen kann, muss ein ACL-Auswertungsalgorithmus absolviert werden. Grundsätzlich werden dabei 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. Dabei werden die Zugangsrechte der einzelnen Einträge getrennt ausgewertet.
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 Rechte, gibt wiederum ein beliebiger von ihnen den Ausschlag für das Endresultat „Zugriff verweigert“.