Dateiberechtigungen mit chmod und chown richtig setzen

1. Das Berechtigungsmodell: read, write, execute

Jede Datei und jedes Verzeichnis unter Linux besitzt drei Berechtigungsklassen: User (Besitzer), Group (Gruppe) und Other (alle übrigen). Für jede dieser drei Klassen existieren unabhängig voneinander die Rechte read (r), write (w) und execute (x). Bei einer Datei bedeutet r lesen, w verändern oder löschen des Inhalts und x ausführen. Bei einem Verzeichnis bedeutet r den Inhalt auflisten, w Dateien anlegen oder entfernen und x in das Verzeichnis wechseln beziehungsweise auf enthaltene Dateien zugreifen können.

Genau dieser letzte Punkt wird häufig übersehen: Ohne Execute-Bit auf einem Verzeichnis ist es egal, ob eine Datei darin lesbar ist, denn der Zugriffspfad selbst wird verweigert. Ein Verzeichnis mit rw- ohne x lässt sich zwar aus ls heraus auflisten, aber kein Prozess kann hineinwechseln oder eine enthaltene Datei öffnen. Das Berechtigungsmodell ist strikt hierarchisch: Der Kernel prüft die Kette von der Wurzel bis zur Zieldatei, und ein fehlendes Execute-Bit an irgendeiner Stelle im Pfad blockiert den gesamten Zugriff, unabhängig von den Rechten auf der Zieldatei selbst.

2. Berechtigungen lesen: ls -l und stat

Der Befehl ls -l zeigt Berechtigungen als zehnstelligen String, etwa -rwxr-xr--. Das erste Zeichen kennzeichnet den Dateityp (- für reguläre Datei, d für Verzeichnis, l für Symlink), gefolgt von drei Dreiergruppen für User, Group und Other. Im Beispiel hat der Besitzer rwx, die Gruppe r-x und alle anderen nur r--. Wer die einzelnen Bits schnell interpretieren will, addiert die Werte read=4, write=2, execute=1 pro Gruppe: rwx ergibt 7, r-x ergibt 5, r-- ergibt 4, zusammen also die oktale Notation 754.

Für eine maschinenlesbare oder skriptfreundliche Ausgabe eignet sich stat besser als ls. Mit stat -c "%a %U:%G %n" datei.txt liefert der Befehl direkt die oktale Berechtigung, den Besitzer und die Gruppe in einer Zeile, ideal für Deployment-Skripte, die vor einem Rollout Berechtigungen prüfen oder protokollieren wollen. In CI-Pipelines ist stat gegenüber dem Parsen von ls -l deutlich robuster, da das Ausgabeformat von ls je nach Distribution und Locale leicht variieren kann.

3. chmod symbolisch: u, g, o, a und +/-/=

Die symbolische Notation von chmod adressiert Klassen mit u (user), g (group), o (other) oder a (all) und verändert Rechte mit den Operatoren + (hinzufügen), - (entfernen) und = (exakt setzen, alle anderen Bits dieser Klasse werden dabei überschrieben). Der große Vorteil gegenüber der oktalen Schreibweise: Symbolische Änderungen sind relativ zum aktuellen Zustand und verändern gezielt nur die genannten Bits, ohne die übrigen Berechtigungen zu kennen oder zu berechnen. chmod g+w datei.sh fügt der Gruppe Schreibrechte hinzu, ohne User- oder Other-Bits anzufassen.

Besonders nützlich ist das großgeschriebene X in chmod -R a+X verzeichnis/: Es setzt das Execute-Bit nur bei Verzeichnissen und bei Dateien, die bereits für irgendeine Klasse ausführbar sind. Reguläre Textdateien und Bilder bleiben unangetastet, während Verzeichnisse durchquerbar werden. Das ist der korrekte Weg, um nach einem Entpacken oder einer Migration rekursiv Zugriff auf einen Verzeichnisbaum herzustellen, ohne versehentlich jede Datei ausführbar zu machen, wie es chmod -R a+x ohne Großschreibung tun würde.

#!/usr/bin/env bash
# Symbolic chmod notation: classes u/g/o/a, operators +/-/=
set -euo pipefail

# Add execute for the owner only
chmod u+x deploy.sh

# Remove write access for group and other
chmod go-w config/secrets.php

# Set exact permissions for other: read-only, overwrites existing bits
chmod o=r public/index.php

# Combine multiple classes and operators in one call
chmod u+rwx,g+rx,o-rwx private-script.sh

# Recursively grant execute only on directories and already-executable files
# Regular files (images, text) stay untouched
chmod -R a+X /var/www/html/pub/media

# Verify the result
stat -c "%a %n" deploy.sh config/secrets.php public/index.php

4. chmod oktal: Zahlen statt Buchstaben

Die oktale Notation beschreibt alle drei Klassen gleichzeitig als dreistellige Zahl. Jede Ziffer ist die Summe aus read=4, write=2 und execute=1 für User, Group und Other in dieser Reihenfolge. 755 bedeutet: Besitzer hat rwx (4+2+1=7), Gruppe und Other haben r-x (4+0+1=5). 644 bedeutet: Besitzer hat rw- (4+2=6), Gruppe und Other haben nur r-- (4). Diese beiden Werte sind die mit Abstand häufigsten Baselines in der Webserver-Administration: 755 für Verzeichnisse und ausführbare Skripte, 644 für normale Dateien wie PHP-Klassen, Konfigurationsdateien oder Assets.

Der oktale Modus ist absolut, nicht relativ: chmod 644 datei.php setzt exakt diesen Zustand, unabhängig davon, welche Rechte vorher galten. Das macht ihn ideal für reproduzierbare Deployment-Skripte, in denen ein definierter Endzustand garantiert werden muss, aber ungeeignet, wenn nur ein einzelnes Bit relativ zum bestehenden Zustand geändert werden soll. Ein häufiger Anfängerfehler ist chmod 777, das allen drei Klassen volle Rechte gibt. Auf einem produktiven Webserver öffnet das jedem lokalen Prozess und im schlimmsten Fall jedem Angreifer mit Codeausführung die Tür zu beliebigen Schreibzugriffen.

#!/usr/bin/env bash
# Octal chmod: absolute mode, common values for web roots
set -euo pipefail

# 755 = rwxr-xr-x: directories and executable scripts
chmod 755 /var/www/html/bin/n98-magerun2.phar

# 644 = rw-r--r--: regular files, no execute bit
chmod 644 /var/www/html/app/etc/env.php

# 750 = rwxr-x---: directory readable/executable only by owner and group
chmod 750 /var/www/html/var/log

# 640 = rw-r-----: sensitive config, no world-readable access
chmod 640 /var/www/html/.env

# NEVER on a production web root: gives write access to everyone
# chmod -R 777 /var/www/html

# Bulk-fix a tree correctly: directories 755, files 644, separately
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

5. chown und chgrp: Besitzer und Gruppe ändern

Während chmod festlegt, was eine Klasse darf, legt chown fest, wem eine Datei gehört und chgrp, welcher Gruppe sie zugeordnet ist. Beide Angaben lassen sich mit chown auch kombiniert setzen: chown benutzer:gruppe datei ändert Besitzer und Gruppe in einem Aufruf. Nur root darf den Besitzer einer Datei auf einen anderen Benutzer übertragen, während der aktuelle Besitzer die Gruppe auf jede Gruppe ändern darf, in der er selbst Mitglied ist. Diese Einschränkung verhindert, dass Benutzer beliebig Speicherplatz-Quotas anderer Accounts belasten, indem sie Dateien einfach umbesitzen.

Auf einem Webserver ist die korrekte Ownership genauso wichtig wie die korrekten Modus-Bits: Der Webserver-Prozess läuft in aller Regel unter einem eigenen Systembenutzer wie www-data, und nur dieser Benutzer beziehungsweise seine Gruppe sollten Schreibzugriff auf die Anwendung haben. Der Befehl chown -R www-data:www-data /var/www/html setzt Besitzer und Gruppe rekursiv für den gesamten Baum. Für gemischte Deploy-Workflows, in denen ein Entwickler-User Dateien hochlädt, aber der Webserver sie später beschreiben muss, ist eine gemeinsame Gruppe mit korrektem Group-Write-Bit oft die sauberere Lösung als ständiges Umbesitzen.

#!/usr/bin/env bash
# chown / chgrp: ownership vs. permission bits
set -euo pipefail

# Change owner and group in a single call
chown deploy:www-data /var/www/html/app/etc/env.php

# Change only the group, owner keeps deploy
chgrp www-data /var/www/html/var/cache

# Recursively hand the whole web root to the webserver user
chown -R www-data:www-data /var/www/html

# Copy ownership from a reference file to a target
chown --reference=/var/www/html/index.php /var/www/html/pub/index.php

# Common mixed-workflow pattern: deploy user owns files,
# webserver group can write via shared group + group-write bit
usermod -aG www-data deploy
chown -R deploy:www-data /var/www/html
find /var/www/html/var /var/www/html/pub/media -type d -exec chmod 2775 {} \;

6. Spezialbits: setuid, setgid und Sticky Bit

Neben den neun klassischen rwx-Bits kennt Linux drei Spezialbits, die als vierte oktale Ziffer vorangestellt werden. setuid (Wert 4, symbolisch s anstelle des Execute-Bits beim User) lässt ein ausführbares Programm mit den Rechten des Dateibesitzers laufen, unabhängig davon, wer es startet. Das klassische Beispiel ist /usr/bin/passwd, das kurzzeitig Root-Rechte braucht, um /etc/shadow zu schreiben. setgid (Wert 2) hat bei Programmen einen analogen Effekt für die Gruppe, bei Verzeichnissen sorgt es dafür, dass neu erstellte Dateien automatisch die Gruppe des Verzeichnisses erben statt der primären Gruppe des erstellenden Benutzers.

Das Sticky Bit (Wert 1, sichtbar als t am Ende der Other-Klasse) wird fast ausschließlich auf Verzeichnissen eingesetzt und verhindert, dass Benutzer fremde Dateien löschen oder umbenennen können, selbst wenn sie Schreibrecht auf das Verzeichnis haben. /tmp trägt standardmäßig 1777, also volle Rechte für alle plus Sticky Bit, damit jeder dort Dateien anlegen, aber nur eigene Dateien löschen kann. Für gemeinsam genutzte Upload- oder Cache-Verzeichnisse in Webanwendungen ist die Kombination chmod 2775 (setgid plus Gruppenschreibrecht) ein bewährtes Muster, damit alle Mitglieder einer Deploy-Gruppe konsistent schreiben können.

7. umask: Standardrechte neuer Dateien steuern

umask legt fest, welche Berechtigungen neu erstellten Dateien und Verzeichnissen standardmäßig entzogen werden, nicht welche gesetzt werden. Der Wert wird von den theoretischen Maximalrechten subtrahiert: Verzeichnisse starten bei 777, Dateien aus Sicherheitsgründen bei 666 (kein Execute-Bit per Default). Eine umask von 022 entzieht Gruppe und Other jeweils das Schreibrecht, sodass neue Verzeichnisse mit 755 und neue Dateien mit 644 entstehen, exakt die Baseline, die auf den meisten Webservern gewünscht ist. Der aktuelle Wert lässt sich mit dem Befehl umask ohne Argument anzeigen.

Für Systeme mit mehreren Entwicklern in einer gemeinsamen Deploy-Gruppe ist umask 002 oft passender: Es entzieht nur Other das Schreibrecht und lässt der Gruppe volle Rechte, sodass jedes neu angelegte File von allen Gruppenmitgliedern beschreibbar bleibt. Die Standard-umask für einen Login-Benutzer wird meist in /etc/login.defs oder /etc/profile konfiguriert, für einzelne Systemdienste lässt sie sich zusätzlich in der jeweiligen systemd-Unit über die Direktive UMask= überschreiben, unabhängig vom Wert des ausführenden Benutzers.

# /etc/login.defs: default umask applied at login for all users
# 022 removes write access for group and other:
# new directories become 755, new files become 644
UMASK           022

# For a shared deploy group where group members must write
# to freshly created files (e.g. shared upload directories):
# UMASK           002

# Per-user override in ~/.bashrc or ~/.profile takes precedence:
# umask 027   # stricter: group gets read-only, other gets nothing

8. ACLs: Berechtigungen jenseits von rwx

Das klassische Unix-Modell kennt nur eine einzige Gruppe pro Datei. Sobald mehrere Benutzergruppen mit unterschiedlichen Rechten auf denselben Pfad zugreifen sollen, etwa ein Deploy-Team und ein separates Monitoring-Team, reicht das klassische Modell nicht mehr aus. Access Control Lists (ACLs) erweitern das Modell um beliebig viele zusätzliche Benutzer- und Gruppeneinträge pro Datei. Mit setfacl -m u:monitoring:r-x /var/www/html/var/log erhält der Benutzer monitoring Lese- und Durchsuchungsrechte auf ein Verzeichnis, ohne dass sich die klassischen rwx-Bits oder die primäre Gruppe ändern.

Gesetzte ACL-Einträge werden in der Ausgabe von ls -l durch ein angehängtes + nach den regulären Berechtigungsbits sichtbar, die Details liefert getfacl datei. Besonders wertvoll sind Default-ACLs auf Verzeichnissen (setfacl -d): Sie werden automatisch an jede neu erstellte Datei und jedes neue Unterverzeichnis vererbt, vergleichbar mit dem setgid-Bit, aber mit voller Kontrolle über beliebige Benutzer statt nur der Gruppe. Voraussetzung ist ein Dateisystem mit aktivierter ACL-Unterstützung, unter ext4 und XFS ist das inzwischen der Standard, muss aber bei älteren Mount-Optionen mit acl explizit aktiviert sein.

9. Die korrekte Baseline für Magento-Webroots

Ein Magento-Webroot braucht ein klares, wiederholbares Berechtigungsschema, weil PHP-FPM unter www-data läuft, Deploy-Prozesse aber häufig unter einem separaten Benutzer erfolgen. Die bewährte Baseline: Alle Verzeichnisse erhalten 755, alle Dateien 644, der komplette Baum gehört www-data:www-data. Ausnahmen sind gezielt beschreibbare Verzeichnisse, die PHP zur Laufzeit selbst befüllt: var/, generated/, pub/media/ und pub/static/ müssen für den Webserver-Prozess durchgehend schreibbar bleiben, sonst schlagen Cache-Generierung, Layout-Kompilierung und Bild-Uploads fehl. app/etc/env.php mit den Datenbankzugangsdaten sollte enger gefasst sein als der Rest, üblicherweise 640 statt 644.

Nach jedem Deploy per Git oder Composer sollten Berechtigungen automatisiert korrigiert werden, nicht manuell nachjustiert. Ein Fix-Skript, das getrennt nach Verzeichnissen und Dateien filtert und anschließend die Laufzeit-Verzeichnisse gesondert öffnet, verhindert die schleichende Drift, bei der einzelne Dateien im Laufe der Zeit falsche Owner oder zu weite Rechte ansammeln, meist weil jemand unter Zeitdruck einmal chmod 777 als schnelle Lösung genutzt hat.

#!/usr/bin/env bash
# fix-permissions.sh: correct baseline for a Magento web root
set -euo pipefail

readonly WEBROOT="/var/www/html"
readonly WEB_USER="www-data"
readonly WEB_GROUP="www-data"

# Ownership: the entire tree belongs to the webserver user
chown -R "${WEB_USER}:${WEB_GROUP}" "$WEBROOT"

# Baseline: 755 for directories, 644 for files
find "$WEBROOT" -type d -exec chmod 755 {} \;
find "$WEBROOT" -type f -exec chmod 644 {} \;

# Runtime-writable directories PHP fills at request time
for dir in var generated pub/media pub/static; do
  chmod -R u+w,g+w "${WEBROOT}/${dir}"
done

# Tighten the credentials file beyond the baseline
chmod 640 "${WEBROOT}/app/etc/env.php"

echo "[OK] Permission baseline restored for ${WEBROOT}"

10. Zusammenfassung

Dateiberechtigungen mit chmod und chown folgen einem klaren, wiederkehrenden Muster: Das rwx-Modell für User, Group und Other regelt Lese-, Schreib- und Ausführungsrechte, wobei das Execute-Bit auf Verzeichnissen über den reinen Zugriffspfad entscheidet. Symbolische Notation mit u/g/o/a und +/-/= eignet sich für gezielte, relative Änderungen, oktale Notation wie 755 und 644 für reproduzierbare, absolute Baselines. chown und chgrp regeln Ownership getrennt von den Modus-Bits, Spezialbits wie setgid und Sticky Bit lösen Sonderfälle bei gemeinsam genutzten Verzeichnissen.

umask bestimmt die Standardrechte neuer Dateien, ACLs erweitern das Modell für Fälle mit mehr als einer relevanten Gruppe. Für Magento-Webroots hat sich eine feste Baseline bewährt: 755 für Verzeichnisse, 644 für Dateien, www-data-Ownership über den gesamten Baum, mit gezielt geöffneten Laufzeit-Verzeichnissen wie var/, generated/ und pub/media/ sowie einer enger gefassten env.php. Wer diese Baseline nach jedem Deploy automatisiert wiederherstellt, verhindert die schleichende Drift, die sonst über Monate zu unkontrollierten Zugriffsrechten führt.

11. FAQ: Dateiberechtigungen mit chmod und chown