35.3. Umgang mit ACLs

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

user::rwx

named user

user:name:rwx

owning group

group::rwx

named group

group:name:rwx

mask

mask::rwx

other

other::rwx

Tabelle 35.2. Maskierung von Zugriffsrechten

Typ

Textform

Rechte

named user

user:geeko:r-x

r-x

mask

mask::rw-

rw-

Wirksame Berechtigungen:

r--

35.3.1. ACL-Einträge und Berechtigungsbits

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.

Abbildung 35.1. Minimale ACL: ACL-Einträge vs. Berechtigungsbits

Minimale ACL: ACL-Einträge vs. Berechtigungsbits

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.

Abbildung 35.2. Erweiterte ACL: ACL-Einträge vs. Berechtigungsbits

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. Werden Berechtigungsbits geändert, spiegelt sich dies in der ACL wider und umgekehrt.

35.3.2. Ein Verzeichnis mit Access ACL

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.

35.3.3. Ein Verzeichnis mit Default ACL

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.

35.3.3.1. Auswirkungen einer Default ACL

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.

35.3.3.2. Default ACLs in der Praxis

Die drei folgenden Beispiele führen Sie an die wichtigsten Operationen an Verzeichnissen und Default ACLs heran:

  1. 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.

  2. 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.

  3. 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.

35.3.4. Auswertung einer ACL

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“.


SUSE LINUX Administrationshandbuch 9.3