ACLs: Erweiterte Berechtigungen jenseits von chmod

1. Das Limit von chmod: ein Owner, eine Gruppe

Das klassische Unix-Berechtigungsmodell kennt für jede Datei genau drei Zielgruppen: den Besitzer, eine einzige zugeordnete Gruppe und den Rest der Welt. chmod und chown decken damit einen Großteil des Alltags ab, stoßen aber an eine harte Grenze, sobald mehr als eine Gruppe gleichzeitig unterschiedliche Rechte auf denselben Pfad braucht. Ein typisches Beispiel: Ein Verzeichnis gehört dem Systembenutzer eines Dienstes, etwa redis oder www-data, ein Deploy-Team soll dort aber ebenfalls schreiben dürfen, ohne die primäre Gruppe der Datei zu ändern oder den Dienst-Account in eine fremde Gruppe zu zwingen.

Mit reinem chmod bleiben in so einem Fall nur unschöne Kompromisse: entweder die Gruppe wechseln und damit die ursprüngliche Ownership-Logik des Dienstes durchbrechen, oder Other-Rechte vergeben und damit jedem lokalen Prozess Zugriff einräumen. Beide Wege verletzen das Prinzip der minimalen Rechtevergabe. Access Control Lists (ACLs) lösen genau dieses Problem: Sie erweitern jede Datei und jedes Verzeichnis um eine beliebige Anzahl zusätzlicher Benutzer- und Gruppeneinträge, vollständig unabhängig von der primären Ownership. Die klassischen rwx-Bits bleiben dabei vollständig erhalten und werden nur ergänzt, nicht ersetzt.

ACLs sind kein Ersatz für chmod, sondern eine gezielte Erweiterung für Sonderfälle. Auf den meisten Servern reichen Owner, Gruppe und umask für 95 Prozent aller Pfade vollkommen aus. Die restlichen 5 Prozent, geteilte Verzeichnisse zwischen mehreren Teams, Monitoring-Zugriffe auf Log-Verzeichnisse fremder Dienste oder Deploy-Pipelines mit eingeschränkten Rechten, sind genau die Fälle, in denen ACLs ihren Wert entfalten.

2. getfacl: ACL-Einträge auslesen und verstehen

Bevor man Rechte setzt, sollte man den aktuellen Zustand kennen. Der Befehl getfacl datei zeigt alle Einträge einer Datei oder eines Verzeichnisses in einem lesbaren Format: Owner, Gruppe, die klassischen rwx-Bits als user::, group:: und other:: sowie zusätzliche Einträge als user:name:rwx beziehungsweise group:name:rwx. Ein zusätzlicher Eintrag namens mask:: begrenzt die effektiven Rechte aller benannten Benutzer- und Gruppeneinträge, dazu mehr im Abschnitt zur ACL-Maske weiter unten.

Ein Hinweis auf gesetzte ACL-Einträge findet sich bereits vor dem Aufruf von getfacl: ls -l hängt bei Dateien mit ACL ein zusätzliches + nach den regulären neun Berechtigungszeichen an, zum Beispiel drwxr-x---+. Dieses Plus-Zeichen ist der einzige Hinweis in der Standardausgabe, die eigentlichen Details liefert immer getfacl. Für die Analyse ganzer Verzeichnisbäume eignet sich getfacl -R verzeichnis/, das rekursiv alle ACL-Einträge ausgibt und sich hervorragend als Textbasis für Diffs zwischen zwei Serverständen eignet. Eine typische Ausgabe fasst Owner, Gruppe und alle Einträge kompakt zusammen: user::rwx, user:deploy:rwx, group::r-x, group:monitoring:r-x, mask::rwx und other::---, jede Zeile ein eigener Berechtigungssatz.

3. setfacl: Einträge setzen, ändern, entfernen

Der Befehl setfacl setzt, ändert und entfernt ACL-Einträge. Die Option -m (modify) fügt einen Eintrag hinzu oder überschreibt ihn, wenn er bereits existiert: setfacl -m u:deploy:rwx datei gibt dem Benutzer deploy volle Rechte, ohne die klassischen Owner- und Gruppenrechte zu berühren. Für Gruppen funktioniert das analog mit g: statt u:, etwa setfacl -m g:monitoring:r-x verzeichnis. Mehrere Einträge lassen sich in einem Aufruf kommasepariert setzen, was Skripte kompakter macht und die Anzahl der Prozessaufrufe reduziert.

Zum Entfernen eines einzelnen Eintrags dient -x (remove): setfacl -x u:deploy datei entfernt genau diesen Eintrag, ohne andere ACL-Einträge oder die klassischen Bits zu verändern. Um sämtliche erweiterten ACL-Einträge auf einmal zu entfernen und zur reinen chmod-Logik zurückzukehren, eignet sich setfacl -b datei. Die Option -R wendet jede dieser Operationen rekursiv auf einen ganzen Verzeichnisbaum an, was in Kombination mit -d für Default-ACLs besonders relevant wird. Wichtig: setfacl ohne -m oder -x, sondern mit bloßem --set, ersetzt die komplette ACL und nicht nur einzelne Einträge, was schnell zu ungewollten Rechteverlusten führt, wenn man es mit -m verwechselt.

#!/usr/bin/env bash
# setfacl: modify, remove, and reset ACL entries
set -euo pipefail

# Grant a user read/write/execute without touching owner or group
setfacl -m u:deploy:rwx /var/www/shared-uploads

# Grant a group read/traverse access
setfacl -m g:monitoring:r-x /var/www/shared-uploads

# Multiple entries in one call, comma-separated
setfacl -m u:deploy:rwx,g:monitoring:r-x,u:backup:r-x /var/www/shared-uploads

# Remove a single named entry, leave everything else untouched
setfacl -x u:deploy /var/www/shared-uploads

# Remove ALL extended ACL entries, fall back to plain chmod bits
setfacl -b /var/www/shared-uploads

# Apply recursively to an entire tree
setfacl -R -m u:deploy:rwx /var/www/shared-uploads

4. Praxisbeispiel: Deploy-User schreibt in fremdes Verzeichnis

Ein konkretes Szenario aus dem Betriebsalltag: Ein Cache-Verzeichnis gehört dem Systembenutzer eines Dienstes, etwa redis:redis, mit strikter Baseline 750. Ein separater Deploy-Benutzer deploy, der über CI/CD-Pipelines Konfigurationsdateien in dieses Verzeichnis schreibt, soll Schreibzugriff erhalten, ohne dass der Dienst-Account in eine fremde Gruppe aufgenommen oder die Ownership verändert werden muss. Ohne ACLs bliebe nur, deploy in die Gruppe redis aufzunehmen, was diesem Benutzer sofort Zugriff auf sämtliche Pfade gibt, die dieser Gruppe gehören, weit über das eine Zielverzeichnis hinaus.

Mit einer gezielten ACL bleibt der Zugriff exakt auf den benötigten Pfad begrenzt: setfacl -m u:deploy:rwx /var/lib/redis/config gibt deploy volle Rechte auf genau dieses Verzeichnis, während Owner und Gruppe unverändert bei redis:redis bleiben. Für Verzeichnisse mit vielen Unterordnern kombiniert man das mit -R, um den bestehenden Baum vollständig abzudecken. Entscheidend ist, dass diese Lösung auch bei einem späteren Wechsel des Dienst-Accounts oder einer Neuinstallation des Dienstes stabil bleibt, solange die ACL nach einem Reinstall erneut gesetzt wird, denn ACLs werden nicht automatisch von Paketmanagern verwaltet.

Für Magento-Setups ist das Muster besonders relevant, wenn ein separater Reporting- oder Backup-Dienst Lesezugriff auf var/log braucht, das dem PHP-FPM-Benutzer gehört. Statt den Backup-Benutzer in die www-data-Gruppe aufzunehmen und damit potenziell Schreibrechte auf die gesamte Anwendung zu eröffnen, genügt ein gezielter r-x-Eintrag für genau diesen Pfad.

#!/usr/bin/env bash
# Grant a deploy user write access to a directory owned
# by an unrelated service account, without group changes
set -euo pipefail

readonly TARGET_DIR="/var/lib/redis/config"
readonly DEPLOY_USER="deploy"
readonly READONLY_USER="backup"

# Confirm current ownership stays with the service account
stat -c "%U:%G %n" "$TARGET_DIR"   # redis:redis /var/lib/redis/config

# Grant the deploy user full access, scoped to this path only
setfacl -R -m u:${DEPLOY_USER}:rwx "$TARGET_DIR"

# Grant a backup service read-only traversal, no write at all
setfacl -R -m u:${READONLY_USER}:r-x "$TARGET_DIR"

# Verify: ownership is unchanged, ACL grants the extra access
getfacl "$TARGET_DIR" | grep -E "^(user|owner|group):"

5. Default-ACLs: Vererbung für neu erstellte Dateien

Eine normale ACL gilt nur für die Datei oder das Verzeichnis, auf der sie gesetzt wurde. Neue Dateien, die später in einem Verzeichnis entstehen, erben davon nichts. Genau dafür gibt es Default-ACLs, gesetzt mit dem Präfix d: beziehungsweise der Option -d: setfacl -d -m u:deploy:rwx verzeichnis/ sorgt dafür, dass jede neue Datei und jedes neue Unterverzeichnis, das ab diesem Zeitpunkt innerhalb des Verzeichnisses angelegt wird, automatisch denselben ACL-Eintrag erhält. Das ist vergleichbar mit dem setgid-Bit, bietet aber volle Kontrolle über beliebige Benutzer statt nur über die Gruppe.

Default-ACLs werden getrennt von den regulären Access-ACLs gespeichert, ein Verzeichnis kann also gleichzeitig eine aktuelle Access-ACL für sich selbst und eine Default-ACL für zukünftige Inhalte tragen. In der Ausgabe von getfacl erscheinen Default-Einträge mit vorangestelltem default:. Wichtig ist der Unterschied bei Dateien und Verzeichnissen: Eine Default-ACL, die Execute-Rechte vergibt, macht neue Dateien nicht automatisch ausführbar, denn das Executable-Bit einer Datei wird weiterhin durch die interne Maske und den ursprünglichen Erstellungsmodus begrenzt. Neue Unterverzeichnisse hingegen erben sowohl die Access-ACL als auch die Default-ACL des Elternverzeichnisses, wodurch sich die Vererbung beliebig tief fortsetzt.

#!/usr/bin/env bash
# Default ACLs: automatic inheritance for future files
set -euo pipefail

readonly SHARED_DIR="/var/www/shared-uploads"

# Set both an access ACL (applies now) and a default ACL
# (applies to every file/subdir created from now on)
setfacl -m u:deploy:rwx,g:monitoring:r-x "$SHARED_DIR"
setfacl -d -m u:deploy:rwx,g:monitoring:r-x "$SHARED_DIR"

# Create a new file as another user, then verify inheritance
sudo -u www-data touch "${SHARED_DIR}/report-2026-07-12.json"
getfacl "${SHARED_DIR}/report-2026-07-12.json"

# Expected: user:deploy:rwx and group:monitoring:r-x
# appear automatically, without any manual setfacl call

# Remove only the default ACL, keep the current access ACL intact
setfacl -k "$SHARED_DIR"

6. Die ACL-Maske: der unterschätzte Faktor

Jede erweiterte ACL besitzt einen Eintrag mask::, der die maximal effektiven Rechte für alle benannten Benutzer- und Gruppeneinträge sowie die Owning-Gruppe begrenzt. Der klassische user::-Eintrag des Besitzers ist von der Maske ausgenommen, alles andere nicht. Setzt man setfacl -m u:deploy:rwx datei auf einer Datei, deren Maske nur r-x erlaubt, erhält deploy in der Praxis trotzdem nur r-x, obwohl der Eintrag rwx anzeigt. getfacl markiert diese Diskrepanz mit einem #effective:-Kommentar direkt hinter dem betroffenen Eintrag, ein Detail, das in der Standardausgabe leicht übersehen wird.

setfacl berechnet die Maske standardmäßig automatisch als Vereinigung aller gesetzten Rechte, sodass dieses Problem im Normalfall nicht auftritt. Es wird relevant, sobald chmod nach dem Setzen von ACL-Einträgen auf dieselbe Datei angewendet wird: chmod auf einer Datei mit ACL verändert nämlich nicht die Gruppenrechte im klassischen Sinne, sondern direkt die Maske. Ein späteres chmod g-w datei kann dadurch versehentlich alle benannten ACL-Einträge einschränken, selbst wenn diese explizit rwx vorsehen. Die Maske explizit mit setfacl -m m::rwx datei zu setzen, ist der zuverlässigste Weg, dieses Verhalten zu kontrollieren, statt sich auf implizite Neuberechnung zu verlassen.

7. ACLs sichern, kopieren und wiederherstellen

ACL-Einträge werden von Standard-Backup-Tools wie tar ohne die Option --acls stillschweigend verworfen, und cp ohne -p beziehungsweise --preserve=all übernimmt sie ebenfalls nicht. Wer ACLs auf produktiven Verzeichnissen einsetzt, muss diese Optionen explizit in Backup- und Deploy-Skripte einbauen, sonst gehen die erweiterten Rechte beim nächsten Restore lautlos verloren, ohne dass ein Fehler gemeldet wird. Das ist eine der häufigsten Ursachen für scheinbar spontan verschwindende Berechtigungen nach einer Server-Migration.

Für gezielte Sicherung und Wiederherstellung eignet sich das Paar getfacl -R und setfacl --restore: Ein rekursiver getfacl-Dump lässt sich als Textdatei versionieren und mit setfacl --restore=datei auf einem anderen Server oder nach einem Rebuild vollständig wiederherstellen. Dieses Vorgehen ist besonders für Disaster-Recovery-Pläne wertvoll, da es ACL-Zustände unabhängig vom eigentlichen Dateiinhalt dokumentiert und reproduzierbar macht, ohne auf ein spezielles Backup-Format angewiesen zu sein.

#!/usr/bin/env bash
# Backing up and restoring ACLs independently of file content
set -euo pipefail

readonly TARGET="/var/www/shared-uploads"
readonly ACL_DUMP="/var/backups/acl/shared-uploads.acl"

# tar preserves ACLs only with --acls, cp only with --preserve=all
tar --acls -czf /var/backups/shared-uploads.tar.gz "$TARGET"
cp -a --preserve=all "$TARGET" /mnt/backup/shared-uploads

# Dedicated ACL snapshot, independent of file content
mkdir -p "$(dirname "$ACL_DUMP")"
getfacl -R "$TARGET" > "$ACL_DUMP"

# Restore ACLs on a rebuilt directory tree after migration
setfacl --restore="$ACL_DUMP"

echo "[OK] ACL snapshot restored from ${ACL_DUMP}"

8. Dateisystem-Voraussetzungen und Mount-Optionen

ACLs sind keine reine Userland-Funktion, sondern müssen vom Dateisystem selbst unterstützt und aktiviert sein. Unter aktuellen ext4- und XFS-Installationen ist ACL-Unterstützung inzwischen standardmäßig aktiv, ohne dass eine explizite Mount-Option nötig ist. Auf älteren Systemen oder bei manuell erstellten /etc/fstab-Einträgen kann es jedoch vorkommen, dass die Option fehlt und setfacl mit der Fehlermeldung Operation not supported abbricht. In diesem Fall muss acl explizit als Mount-Option ergänzt und die Partition neu eingehängt werden.

Vor jedem produktiven Einsatz lohnt sich eine kurze Prüfung mit tune2fs -l /dev/sdX | grep "Default mount options" bei ext-Dateisystemen, um zu sehen, ob acl bereits als Default-Option im Superblock verankert ist. Fehlt sie, lässt sie sich dauerhaft mit tune2fs -o acl /dev/sdX setzen, ganz ohne Änderung an /etc/fstab. Netzwerkdateisysteme wie NFS benötigen zusätzlich eine passende NFSv4-ACL-Unterstützung auf Server- und Client-Seite, die sich von den hier beschriebenen POSIX-ACLs in Detailfragen unterscheidet, im Kern aber demselben Konzept folgt.

# /etc/fstab: ensure ACL support is enabled on the mount
# Modern ext4/XFS defaults already include acl, but older
# or manually written entries may need it explicit.

# UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /var/www ext4 defaults,acl 0 2
/dev/sdb1   /var/www   ext4   defaults,acl   0   2

# Remount without a reboot after editing fstab:
# mount -o remount /var/www

# Persist acl as a default mount option in the ext4 superblock
# tune2fs -o acl /dev/sdb1

9. ACLs im Vergleich zu chmod und chown

Die Wahl zwischen klassischen Berechtigungen und ACLs ist keine Entweder-oder-Entscheidung, sondern eine Frage des passenden Werkzeugs für den jeweiligen Anwendungsfall. Die folgende Tabelle stellt typische Situationen und die jeweils sinnvollere Lösung gegenüber.

Als Faustregel gilt: chmod und chown bleiben die erste Wahl für einfache, klar abgegrenzte Ownership-Verhältnisse. Sobald mehr als eine Gruppe gleichzeitig unterschiedliche Rechte auf denselben Pfad braucht, oder sobald zukünftige Dateien automatisch bestimmte Rechte erben sollen, sind ACLs das präzisere und sicherere Werkzeug, weil sie das Prinzip der minimalen Rechtevergabe einhalten, ohne bestehende Ownership-Strukturen zu verletzen.

10. Zusammenfassung

ACLs erweitern das klassische chmod-Modell genau dort, wo ein einzelner Owner und eine einzige Gruppe nicht ausreichen. getfacl liest bestehende Einträge aus, erkennbar bereits am angehängten + in ls -l. setfacl -m setzt neue Einträge für Benutzer und Gruppen, setfacl -x entfernt einzelne Einträge gezielt, setfacl -b räumt vollständig auf. Ein Deploy-User erhält so Schreibzugriff auf ein fremdes, von einem Dienst-Account verwaltetes Verzeichnis, ohne dass Ownership oder primäre Gruppe angetastet werden müssen.

Default-ACLs mit setfacl -d sorgen dafür, dass diese Rechte automatisch an neu erstellte Dateien und Unterverzeichnisse vererbt werden, vergleichbar mit dem setgid-Bit, aber mit voller Kontrolle über beliebige Benutzer. Die ACL-Maske begrenzt effektive Rechte und verdient besondere Aufmerksamkeit nach nachträglichem chmod. Backup-Tools müssen ACLs explizit mit --acls oder per getfacl-Dump sichern, sonst gehen sie beim Restore lautlos verloren. Für einfache Fälle bleibt chmod die richtige Wahl, für geteilte Verzeichnisse mit mehreren Zugriffsebenen sind ACLs das präzisere Werkzeug.

11. FAQ: ACLs und erweiterte Berechtigungen