Chmod-Berechtigungen verstehen: 755, 644 und Co. erklärt
chmod 755 bedeutet: Der Eigentümer darf lesen, schreiben und ausführen, Gruppe und Andere dürfen nur lesen und ausführen. Als ls -l-String sieht das so aus: rwxr-xr-x. Jede der drei Ziffern in einer chmod-Zahl steht für eine Nutzerklasse, jede Ziffer ist die Summe von Lesen (4), Schreiben (2) und Ausführen (1).
Wie eine Oktalziffer entsteht
Unix-Berechtigungen kennen genau drei Rechte pro Klasse: Lesen, Schreiben, Ausführen. Jedes Recht hat einen festen Bitwert:
- Lesen = 4
- Schreiben = 2
- Ausführen = 1
Eine Ziffer ist einfach die Summe der Rechte, die eine Klasse besitzt. Volle Rechte (lesen, schreiben, ausführen) ergeben 4+2+1 = 7. Nur lesen und schreiben ergibt 4+2 = 6. Nur lesen und ausführen ergibt 4+1 = 5. Es gibt drei solcher Ziffern hintereinander, für Eigentümer, Gruppe und Andere, in genau dieser Reihenfolge. 755 heißt also: Eigentümer = 7 (4+2+1), Gruppe = 5 (4+1), Andere = 5 (4+1).
Bei Verzeichnissen bedeuten die Bits etwas leicht anderes als bei Dateien: Das Ausführen-Bit erlaubt, in ein Verzeichnis hineinzuwechseln (cd), das Lesen-Bit erlaubt, den Inhalt aufzulisten (ls). Ein Verzeichnis, das lesbar, aber nicht ausführbar ist, ist ein klassischer Stolperstein: Manche Tools zeigen dann noch die Dateinamen im Verzeichnis an, aber du kannst weder hineinwechseln noch die einzelnen Dateien stat’en. Ohne das Ausführen-Bit bleibt ein Verzeichnis effektiv verschlossen, egal was das Lesen-Bit erlaubt.
Typische Kombinationen in der Praxis
| Befehl | Oktal | Symbolisch | Typischer Einsatz |
|---|---|---|---|
| chmod 600 file | 600 | rw------- | SSH Private Key (id_rsa), .env-Datei oder Secrets |
| chmod 644 file | 644 | rw-r—r— | Normale Datei (HTML, Config, Log), Eigentümer schreibt, alle lesen |
| chmod 700 dir | 700 | rwx------ | Privates Verzeichnis, nur der Eigentümer kommt hinein |
| chmod 755 script.sh | 755 | rwxr-xr-x | Öffentliches Skript oder Verzeichnis, Eigentümer schreibt, alle können ausführen/hineinwechseln |
| chmod 775 dir | 775 | rwxrwxr-x | Gemeinsames Team-Verzeichnis, Eigentümer und Gruppe dürfen schreiben |
| chmod 777 file | 777 | rwxrwxrwx | Alle dürfen lesen, schreiben, ausführen, vermeiden, Sicherheitsrisiko |
Auffällig ist, wie selten die Andere-Klasse Schreibrechte bekommt: In den ersten fünf Zeilen der Tabelle taucht die 2 (Schreiben) für Andere kein einziges Mal auf. Das ist kein Zufall, sondern gängige Praxis, fremde Nutzer sollen fast nie Schreibzugriff bekommen.
Zwei verschiedene Dinge heißen “symbolisch”
Bei chmod gibt es zwei unterschiedliche Bedeutungen von “symbolisch”, die häufig durcheinandergebracht werden.
Die erste ist die Anzeige-Notation von ls -l, etwa rwxr-xr-x. Das ist eine absolute Momentaufnahme: Sie beschreibt den kompletten aktuellen Zustand aller neun Bits auf einen Blick, genau das, was der Chmod-Rechner unten anzeigt.
Die zweite ist die symbolische Modus-Syntax von chmod selbst, mit der man Rechte relativ verändert, statt die komplette Oktalzahl neu anzugeben:
- chmod u+x file.sh fügt dem Eigentümer (user) das Ausführen-Bit hinzu, alles andere bleibt unverändert
- chmod go-w file entzieht Gruppe (group) und Anderen (others) das Schreibrecht
- chmod a+r file macht die Datei für alle (all) lesbar
Der Unterschied ist wichtig: rwxr-xr-x beschreibt einen Zustand, u+x beschreibt eine Änderung relativ zum bisherigen Zustand. Wer eine Datei nur ausführbar machen will, ohne die restlichen Rechte anzufassen, greift zu u+x statt die komplette Oktalzahl neu zu berechnen.
Probier’s mit deinen eigenen Berechtigungen
Trag eine Oktalzahl ein oder setz die Häkchen direkt, der Rechner zeigt sofort die passende Symbolschreibweise und den fertigen chmod-Befehl zum Kopieren.
| Lesen | Schreiben | Ausführen | |
|---|---|---|---|
| Eigentümer | |||
| Gruppe | |||
| Andere |
Warum neue Dateien automatisch 644 bekommen
Wer nie chmod aufgerufen hat, hat trotzdem schon Dateien mit 644 und Verzeichnisse mit 755 angelegt, ganz ohne es zu wissen. Der Grund ist umask.
Neue Dateien starten von einer Basis von 666 (rw-rw-rw-, ohne Ausführen-Bit, aus Sicherheitsgründen standardmäßig nie ausführbar), neue Verzeichnisse von 777 (rwxrwxrwx). Von dieser Basis wird der umask-Wert der Shell abgezogen. Der Standard-umask auf den meisten Linux-Systemen ist 022. Also: 666 minus 022 ergibt 644 für eine frisch angelegte Datei, 777 minus 022 ergibt 755 für ein frisch angelegtes Verzeichnis. Genau deshalb landen fast alle selbst erstellten Dateien bei 644 und Verzeichnisse bei 755, ohne dass irgendjemand manuell chmod ausgeführt hat.
Häufige Fehler und Sicherheitsrisiken
chmod 777 ist der mit Abstand häufigste Anfängerfehler. Es erlaubt buchstäblich jedem Nutzer auf dem System, die Datei zu lesen, zu schreiben und zu ersetzen, auch einem Angreifer, der bereits einen Fuß in der Tür hat. Ein unsicher hochgeladenes File, das plötzlich 777 hat, ist ein klassischer Weg, wie aus einem harmlosen Upload eine Webshell wird. Sicherheits-Scanner, etwa bei WordPress- oder Hosting-Audits, markieren 777 routinemäßig als kritischen Befund. Die Korrektur ist fast immer 755 für ausführbare Dateien und Verzeichnisse, 644 für normale Dateien, und noch enger auf 750/640, sobald eine vertrauenswürdige Gruppe im Spiel ist.
Der zweite klassische Fehler betrifft SSH-Schlüssel. ssh-keygen erzeugt private Schlüssel standardmäßig mit 600, also nur für den Eigentümer lesbar und schreibbar. Das ist kein Zufall: OpenSSH weigert sich aktiv, einen privaten Schlüssel zu benutzen, der für Gruppe oder Andere lesbar ist, und meldet dann etwas wie “Permissions 0644 for ‘id_rsa’ are too open” oder sogar “UNPROTECTED PRIVATE KEY FILE!”. Wer einen Schlüssel per E-Mail verschickt oder aus einem Archiv entpackt bekommt und dabei die Rechte auf 644 verliert, bekommt genau diese Fehlermeldung beim nächsten ssh-Login und muss manuell wieder auf 600 zurücksetzen.
Was dieser Rechner nicht abdeckt
Zusätzlich zu den drei Standardziffern für Eigentümer, Gruppe und Andere gibt es optional eine vierte, führende Ziffer für die Sonderrechte setuid (4000), setgid (2000) und Sticky Bit (1000), etwa in chmod 4755 oder im klassischen chmod 1777 auf /tmp. Dieser Rechner deckt bewusst nur das dreistellige Standardschema ab. Kurz zur Einordnung: setuid lässt ein Programm mit den Rechten seines Eigentümers laufen (etwa /usr/bin/passwd), das Sticky Bit auf einem für alle beschreibbaren Verzeichnis wie /tmp verhindert, dass ein Nutzer die Dateien eines anderen Nutzers dort löschen kann.
Häufig gestellte Fragen
Was bedeutet chmod 755 genau? Der Eigentümer darf lesen, schreiben und ausführen (7 = 4+2+1), Gruppe und Andere dürfen nur lesen und ausführen (5 = 4+1). Als ls -l-Anzeige ist das rwxr-xr-x. Typisch für öffentliche Skripte und Verzeichnisse, bei denen nur der Eigentümer Änderungen vornehmen soll.
Warum funktioniert mein SSH-Key plötzlich nicht mehr? Vermutlich stimmen die Dateirechte nicht mehr. OpenSSH verweigert private Schlüssel, die für Gruppe oder Andere lesbar sind, und zeigt eine Meldung wie “Permissions 0644 for ‘id_rsa’ are too open”. Die Lösung ist chmod 600 auf die Schlüsseldatei, das ist auch der Standardwert, den ssh-keygen selbst setzt.
Ist chmod 777 immer schlecht? Praktisch ja. 777 gibt jedem Nutzer auf dem System volle Rechte, lesen, schreiben, ausführen, ohne jede Einschränkung. Für Webserver-Dateien ist das ein bekannter Weg, wie ein Upload-Formular zur Sicherheitslücke wird. Fast immer reicht 755 für Skripte und Verzeichnisse oder 644 für normale Dateien.
Was ist der Unterschied zwischen rwxr-xr-x und chmod u+x? rwxr-xr-x ist die Anzeige von ls -l, ein Schnappschuss des kompletten aktuellen Zustands aller neun Bits. chmod u+x ist dagegen eine relative Änderung: Sie fügt nur dem Eigentümer das Ausführen-Bit hinzu und lässt alle anderen Bits unangetastet, ganz ohne die komplette Oktalzahl neu zu berechnen.
Warum sind neue Dateien bei mir immer 644, obwohl ich nie chmod aufgerufen habe? Weil der umask-Wert der Shell automatisch von der Basis 666 abgezogen wird. Mit dem verbreiteten Standard-umask von 022 ergibt das 666 minus 022 gleich 644. Bei Verzeichnissen ist die Basis 777, also 777 minus 022 gleich 755. Das passiert bei jeder neu erstellten Datei automatisch, ganz ohne manuellen chmod-Aufruf.