ACLs unter Linux: Wenn eine Dateigruppe nicht ausreicht

Die klassischen Linux-Dateirechte unterscheiden drei Rollen: den Eigentümer, die Dateigruppe und alle übrigen Benutzer. Für viele Aufgaben genügt dieses Modell. Schwieriger wird es, wenn mehrere Personen oder Gruppen unterschiedliche Zugriffe auf dieselbe Datei benötigen.

ACLs – Access Control Lists – erweitern die klassischen Rechte um Einträge für einzelne Benutzer und zusätzliche Gruppen. Dadurch lässt sich genauer festlegen, wer eine Datei oder ein Verzeichnis nutzen darf, ohne dessen Eigentümer oder Dateigruppe zu ändern.

Der entscheidende Gedanke: ACLs ersetzen das bekannte Berechtigungsmodell nicht. Sie machen es dort feiner, wo eine einzige Dateigruppe die gewünschte Rechteverteilung nicht mehr ausdrücken kann.

Ausgangspunkt: Die Grenzen der klassischen Rechte

Stell dir einen Bericht mit folgender Rechteverteilung vor:

Rolle	Berechtigung
Eigentümer Max	Lesen und Schreiben
Dateigruppe projektteam	Lesen und Schreiben
Andere	Kein Zugriff

Nun kommen zwei Anforderungen hinzu:

• Die Gruppe pruefung soll den Bericht lesen, aber nicht bearbeiten.
• Anna soll ihn bearbeiten dürfen, ohne dafür Mitglied des gesamten Projektteams zu werden.

Mit den drei klassischen Rollen lässt sich diese Kombination nicht unmittelbar darstellen. Die Datei besitzt nur eine Dateigruppe. Eine Freigabe für „Andere“ wäre zu weitreichend, und Annas Aufnahme in das Projektteam könnte ihr Zugriff auf weitere Teamdateien geben.

ACLs ermöglichen stattdessen zusätzliche, direkt an diesem Objekt hinterlegte Benutzer- und Gruppeneinträge. Eigentümer und Dateigruppe bleiben dabei erhalten.

Was eine ACL beschreibt

Eine ACL ist eine Liste von Berechtigungseinträgen. Jeder Eintrag beschreibt, welche der bekannten Rechte r, w und x für eine bestimmte Rolle gelten.

Zu den klassischen Einträgen können weitere hinzukommen:

Eintrag	Bedeutung
Eigentümer	Rechte des Dateieigentümers
Benannter Benutzer	Rechte eines zusätzlich angegebenen Benutzers
Dateigruppe	Rechte der zugeordneten Gruppe
Benannte Gruppe	Rechte einer zusätzlich angegebenen Gruppe
Maske	Obergrenze für bestimmte ACL-Einträge
Andere	Rechte für Prozesse, auf die keine vorherige Benutzer- oder Gruppenzuordnung zutrifft

Eine ACL führt also keine neuen Grundrechte ein. Sie erweitert vor allem die Zahl der Personen und Gruppen, für die sich diese Rechte gezielt festlegen lassen.

Eigentümer und Gruppenmitgliedschaften bleiben unverändert

Wenn Anna einen eigenen ACL-Eintrag erhält, wird sie dadurch weder Eigentümerin noch Mitglied der Dateigruppe.

Ebenso ersetzt ein Eintrag für pruefung nicht die bisherige Dateigruppe projektteam. Beide Gruppen können unterschiedliche Rechte am selben Objekt erhalten.

Das ist der praktische Nutzen: Eine dateibezogene Ausnahme muss nicht durch eine Änderung am gesamten Benutzer- und Gruppenmodell umgesetzt werden.

Voraussetzungen: Dateisystem und Verwaltungswerkzeuge

Die üblichen Linux-Dateisysteme ext4, XFS und Btrfs unterstützen ACLs normalerweise bereits. Voraussetzung ist, dass die Unterstützung im Kernel und für das verwendete Dateisystem aktiviert ist.

Davon zu unterscheiden sind die Verwaltungswerkzeuge: getfacl zeigt ACLs an, setfacl bearbeitet sie. Beide werden häufig über ein separates Paket namens acl bereitgestellt. Dieses Paket liefert die Bedienwerkzeuge – nicht den eigentlichen Mechanismus der Zugriffskontrolle.

Fehlen die Werkzeuge, können bereits vorhandene ACLs trotzdem wirksam sein. Umgekehrt macht die Installation des Pakets ein nicht unterstützendes Dateisystem nicht ACL-fähig.

Ein Beispiel für die gewünschte Rechteverteilung

Für den Bericht könnte die ACL sinngemäß Folgendes ausdrücken:

Benutzer oder Rolle	Gewünschte Rechte
Eigentümer Max	Lesen und Schreiben
Anna	Lesen und Schreiben
Dateigruppe projektteam	Lesen und Schreiben
Zusätzliche Gruppe pruefung	Lesen
Andere	Keine Rechte

Damit wird die Ausnahme direkt dort beschrieben, wo sie benötigt wird: am Bericht.

Anna erhält dadurch keinen allgemeinen Zugriff auf andere Dateien des Projektteams. Die Prüfergruppe kann den Bericht lesen, ohne zugleich zu dessen Dateigruppe werden zu müssen. Solche benannten Einträge sind der Kern der erweiterten Zugriffskontrolle.

ACLs sind Teil der Rechteprüfung – keine zweite Wunschliste

Eine ACL wird nicht unabhängig von den klassischen Rechten ausgewertet und anschließend einfach hinzuaddiert.

Die klassischen Rollen sind selbst Bestandteil des ACL-Modells.

Für gewöhnliche Zugriffe lässt sich die Prüfung vereinfacht so beschreiben:

1. Ist der Prozess dem Eigentümer zugeordnet, gelten die Eigentümerrechte.
2. Andernfalls wird nach einem passenden benannten Benutzereintrag gesucht.
3. Gibt es keinen passenden Benutzereintrag, werden die zutreffenden Gruppeneinträge geprüft.
4. Nur wenn keine passende Benutzer- oder Gruppenzuordnung greift, werden die Rechte für Andere herangezogen.

Ein Benutzereintrag kann auch einschränkend wirken

Angenommen, Anna darf über das Projektteam normalerweise lesen und schreiben. Erhält sie einen eigenen Benutzereintrag mit lediglich Leserecht, wird dieser passende Benutzereintrag maßgeblich.

Sie bekommt dann nicht zusätzlich das Schreibrecht aus der Gruppe. Ein benannter Benutzereintrag ist also nicht automatisch nur eine Erweiterung bestehender Zugriffe.

Das erklärt, warum ACLs nicht als ungeordnete Sammlung von Freigaben verstanden werden sollten. Entscheidend ist, welcher Eintrag bei der Prüfung tatsächlich zur Anwendung kommt.

Die ACL-Maske: Eine gemeinsame Obergrenze

Die ACL-Maske begrenzt die maximal wirksamen Rechte bestimmter Einträge:

• der Dateigruppe;
• zusätzlicher benannter Gruppen;
• zusätzlicher benannter Benutzer.

Die Eigentümerrechte und die Rechte für Andere werden durch diese Maske nicht begrenzt.

Ein Beispiel:

Annas Eintrag:      Lesen und Schreiben
ACL-Maske:          Nur Lesen
Wirksames Ergebnis: Nur Lesen

Annas Eintrag enthält weiterhin Schreibrecht. Die Maske verhindert aber, dass es wirksam wird.

Umgekehrt verteilt die Maske keine Rechte. Enthält sie Lesen und Schreiben, erhält eine Prüfergruppe mit reinem Leserecht dadurch nicht automatisch Schreibrecht. Wirksam ist nur, was sowohl der betreffende Eintrag als auch die Maske zulassen.

ACL-Maske und umask sind nicht dasselbe

Trotz der ähnlichen Namen erfüllen die beiden Masken unterschiedliche Aufgaben:

Mechanismus	Aufgabe
umask	Begrenzt angeforderte Rechte bei der Erstellung neuer Objekte
ACL-Maske	Begrenzt die wirksamen Rechte bestimmter Einträge einer ACL

Die ACL-Maske gehört zur Berechtigungsliste des Objekts. Die umask gehört dagegen zum erstellenden Prozess.

Warum ls -l bei ACLs nicht das ganze Bild zeigt

Die bekannte Ausgabe von ls -l bleibt nutzbar. Bei erweiterten ACLs erscheint normalerweise ein Pluszeichen hinter der Rechtezeichenfolge:

-rw-rw----+

Dieses Zeichen weist darauf hin, dass zusätzliche ACL-Informationen vorhanden sind. Es zeigt aber nicht, welche Benutzer und Gruppen darin vorkommen.

Eine weitere Besonderheit betrifft die mittleren drei Rechtezeichen: Enthält die ACL eine Maske, entsprechen die angezeigten Gruppenbits dieser Maske – nicht ausschließlich dem Eintrag der Dateigruppe.

Ein sichtbares rw- an der Gruppenposition bedeutet dann also nicht zwingend, dass die Dateigruppe selbst tatsächlich lesen und schreiben darf. Es beschreibt die gemeinsame Obergrenze der maskierten Einträge.

Für die vollständige Einordnung ist deshalb die ACL selbst maßgeblich.

Wie ACLs mit chmod zusammenwirken

chmod und ACLs bearbeiten keine vollständig getrennten Berechtigungswelten. Zwischen den klassischen Rechtebits und bestimmten ACL-Einträgen besteht eine feste Verbindung:

Klassische Rechtebits	Entsprechung bei einer erweiterten ACL
Eigentümerbits	Eigentümereintrag
Gruppenbits	ACL-Maske
Andere-Bits	Eintrag für Andere

Eine Änderung der Gruppenbits mit chmod kann daher die Maske verändern und damit die wirksamen Rechte zusätzlicher Benutzer und Gruppen einschränken oder wieder freigeben.

Das ist besonders wichtig, wenn benannte Einträge weiterhin Schreibrecht enthalten, dieses aber momentan durch die Maske begrenzt wird. Wird die Maske später erweitert, kann das hinterlegte Schreibrecht wieder wirksam werden.

Daraus folgt: Auf Dateien mit erweiterten ACLs sollte eine Änderung mit chmod immer im Zusammenhang mit der gesamten Rechteverteilung betrachtet werden.

Access-ACL und Default-ACL unterscheiden

Unter Linux sind zwei Aufgaben voneinander zu trennen.

Access-ACL: Der aktuelle Zugriff

Die Access-ACL bestimmt die Zugriffsrechte auf die konkrete Datei oder das konkrete Verzeichnis.

Bei einem Verzeichnis beantwortet sie beispielsweise, wer dessen Einträge auflisten, das Verzeichnis durchqueren oder darin neue Einträge anlegen darf.

Default-ACL: Eine Vorlage für neue Objekte

Ein Verzeichnis kann zusätzlich eine Default-ACL besitzen. Diese dient als Vorlage für die Access-ACL neu angelegter Dateien und Unterverzeichnisse.

Neu angelegte Unterverzeichnisse können die Default-ACL außerdem als eigene Vorlage übernehmen und sie damit für weitere Ebenen fortführen.

Wichtig sind drei Grenzen:

• Die Default-ACL verändert nicht automatisch bereits vorhandene Dateien.
• Sie bestimmt nicht selbst den aktuellen Zugriff auf das Verzeichnis; dafür ist dessen Access-ACL zuständig.
• Die vom erstellenden Programm angeforderten Rechte begrenzen weiterhin das Ergebnis.

Eine Default-ACL ist somit eine Erstellungsvorlage, keine ständig auf alle darunterliegenden Objekte durchgesetzte Richtlinie.

Default-ACL und umask: Nicht einfach nacheinander anwenden

Ohne Default-ACL entsteht der anfängliche Rechtezustand aus den vom Programm angeforderten Rechten und der umask.

Besitzt das übergeordnete Verzeichnis dagegen eine Default-ACL, wird die neue Access-ACL aus dieser Vorlage abgeleitet. Die angeforderten Erstellungsrechte begrenzen die zugehörigen Einträge. Die umask wird dann nicht zusätzlich auf die gewöhnliche Weise angewendet.

Das erklärt, warum die Rechte neuer Dateien in einem bestimmten Verzeichnis anders aussehen können, als man allein anhand der aktuellen umask erwartet.

Auch hier werden nicht beliebig Rechte hinzugefügt: Fordert ein Programm keine Ausführungsrechte an, macht eine großzügige Default-ACL die neue gewöhnliche Datei nicht automatisch ausführbar.

ACLs ersetzen weder Pfadrechte noch andere Schutzmechanismen

Ein passender ACL-Eintrag an einer Datei löst nicht automatisch alle Zugriffsfragen.

Die Bedeutung von r, w und x bleibt bestehen. Bei Verzeichnissen ist insbesondere das Suchrecht wichtig: Der Prozess muss den Pfad bis zum Ziel durchqueren können. Eine Freigabe nur an der Zieldatei genügt daher nicht, wenn ein übergeordnetes Verzeichnis den Zugang verhindert.

Auch innerhalb einer ACL bleibt zwischen dem Bearbeiten eines Dateiinhalts und dem Entfernen eines Verzeichniseintrags zu unterscheiden. ACLs verwenden dieselben grundlegenden Lese-, Schreib- und Such- beziehungsweise Ausführungsrechte.

Sie sind damit eine Erweiterung der benutzer- und gruppenbezogenen Rechtevergabe, kein allgemeines Umgehen anderer Zugriffsbeschränkungen.

Die Rolle von getfacl und setfacl

Zwei Werkzeuge gehören unmittelbar zum ACL-Modell:

Werkzeug	Aufgabe
getfacl	ACLs anzeigen und gegebenenfalls durch die Maske eingeschränkte Rechte sichtbar machen
setfacl	ACL-Einträge hinzufügen, verändern oder entfernen sowie Default-ACLs verwalten

getfacl zeigt also die vollständige Rechteverteilung, während setfacl sie bearbeitet.

ACLs ändern dürfen grundsätzlich der Eigentümer und entsprechend privilegierte Prozesse. Ein Benutzer mit bloßem Schreibrecht darf deshalb nicht automatisch auch die ACL verwalten.

Änderungen können die Maske beeinflussen

setfacl berechnet die Maske standardmäßig neu, sofern keine abweichende Steuerung oder ausdrücklich vorgegebene Maske verwendet wird.

Deshalb sollte nach einer ACL-Änderung nicht nur der neue Eintrag betrachtet werden, sondern auch die resultierende Maske und die dadurch wirksamen Rechte anderer Einträge.

Wann ACLs sinnvoll sind – und wann Gruppen genügen

ACLs sind besonders hilfreich, wenn eine gemeinsame Grundstruktur um gezielte Ausnahmen ergänzt werden muss:

• Ein Benutzer benötigt Zugriff auf einzelne Dateien, aber nicht auf alle Daten einer Gruppe.
• Mehrere Gruppen benötigen unterschiedliche Rechte am selben Objekt.
• Ein Verzeichnis soll solche zusätzlichen Rechte als Vorlage an neue Objekte weitergeben.

Diese Fälle entsprechen den zusätzlichen Benutzer-, Gruppen- und Default-Einträgen des ACL-Modells.

Wenn dagegen ein klar abgegrenztes Team dieselben Rechte auf einen gemeinsamen Datenbestand benötigt, bleibt eine passende Dateigruppe oft übersichtlicher.

Die organisatorische Leitlinie lautet daher: Gruppen beschreiben gemeinsame Zuständigkeiten; ACLs können zusätzliche objektbezogene Zugriffe ausdrücken.

ACLs müssen bei Datenübernahmen erhalten bleiben

Eine ACL gehört zur Rechteverteilung der Datei. Geht sie beim Kopieren, Sichern oder Wiederherstellen verloren, kann der Zugriff am Ziel anders ausfallen als am Ursprung.

Das Zielsystem und die verwendeten Werkzeuge müssen ACLs deshalb unterstützen und bei der Übertragung berücksichtigen. Die ACL-Dokumentation beschreibt beispielsweise ausdrücklich das Erhalten von ACLs beim Kopieren mit entsprechender Option.

Für eine verlässliche Datenübernahme reicht es somit nicht immer, nur Dateiinhalte, Eigentümer und die sichtbaren neun Rechtebits zu betrachten.

Fazit: Feinere Rechte ohne ein neues Grundmodell

ACLs erweitern die klassischen Linux-Dateirechte um gezielte Einträge für einzelne Benutzer und weitere Gruppen. Sie sind dort sinnvoll, wo eine einzige Dateigruppe die gewünschte Verteilung nicht mehr abbilden kann.

Die wesentlichen Zusammenhänge bleiben überschaubar: Die Access-ACL regelt den aktuellen Zugriff. Die ACL-Maske begrenzt bestimmte Einträge. Eine Default-ACL dient als Vorlage für neue Objekte. chmod bleibt mit diesem Modell verbunden und kann über die Maske auch zusätzliche ACL-Berechtigungen beeinflussen.

ACLs sind damit kein Ersatz für ein durchdachtes Benutzer- und Gruppenmodell. Sie ergänzen es um die Möglichkeit, notwendige Ausnahmen direkt und nachvollziehbar an Dateien und Verzeichnissen festzulegen.