Früher oder später trifft jeder Linux-Nutzer auf die berüchtigte Meldung „Permission denied“. Sie ist kein Fehler des Systems, sondern Ausdruck eines durchdachten Sicherheitsmodells, das seit den Anfängen von Unix für Ordnung sorgt. Wer das Berechtigungssystem versteht, schützt sensible Daten, vermeidet katastrophale Fehler und löst die meisten „Zugriff verweigert“-Probleme in Sekunden. Dieser Artikel erklärt Schritt für Schritt, wie Linux festlegt, wer was mit einer Datei tun darf.
Drei Klassen, drei Rechte
Das klassische Linux-Berechtigungsmodell kennt für jede Datei und jedes Verzeichnis genau drei Benutzerklassen:
- Owner (Benutzer): Der Eigentümer der Datei, meist derjenige, der sie erstellt hat.
- Group (Gruppe): Eine Gruppe von Benutzern, die gemeinsamen Zugriff teilen.
- Others (Andere): Alle übrigen Nutzer des Systems.
Für jede dieser drei Klassen gibt es drei mögliche Rechte:
- r (read, lesen): Den Inhalt einer Datei lesen oder den Inhalt eines Verzeichnisses auflisten.
- w (write, schreiben): Eine Datei ändern oder in einem Verzeichnis Dateien anlegen und löschen.
- x (execute, ausführen): Eine Datei als Programm starten oder ein Verzeichnis betreten.
Eine wichtige Besonderheit: Bei Verzeichnissen bedeutet das Ausführungsrecht nicht „starten“, sondern „hineinwechseln“ und auf die enthaltenen Dateien zugreifen dürfen. Ein Verzeichnis ohne x bleibt verschlossen, selbst wenn du Leserechte hast.
Die Berechtigungsanzeige lesen
Gibst du ls -l ein, beginnt jede Zeile mit einem zehnstelligen Block wie -rwxr-xr--. Diese Zeichenkette erzählt dir die gesamte Berechtigungsgeschichte:
- Das erste Zeichen beschreibt den Typ:
-für eine Datei,dfür ein Verzeichnis,lfür einen symbolischen Link. - Die nächsten drei Zeichen (
rwx) gelten für den Owner. - Die mittleren drei (
r-x) für die Gruppe. - Die letzten drei (
r--) für alle Anderen.
Ein Bindestrich an einer Stelle bedeutet, dass das jeweilige Recht fehlt. -rwxr-xr-- heißt also: Der Owner darf lesen, schreiben und ausführen, die Gruppe lesen und ausführen, alle Anderen nur lesen.
Die oktale Schreibweise
Hinter den Buchstaben steckt ein simples Zahlensystem, das du in jeder Anleitung wiederfindest. Jedes Recht hat einen Wert: read = 4, write = 2, execute = 1. Du addierst die Werte je Klasse zu einer Ziffer:
- 7 = 4+2+1 = rwx (alle Rechte)
- 6 = 4+2 = rw- (lesen und schreiben)
- 5 = 4+1 = r-x (lesen und ausführen)
- 4 = r-- (nur lesen)
- 0 = --- (keine Rechte)
Drei dieser Ziffern hintereinander beschreiben die komplette Berechtigung. Die häufigste Kombination ist 755: Der Owner darf alles (7), Gruppe und Andere dürfen lesen und ausführen (5). Für reine Datendateien ist 644 Standard: Owner liest und schreibt (6), der Rest liest nur (4). Bei sensiblen Dateien wie SSH-Schlüsseln verlangt das System sogar 600 – ausschließlich der Owner hat Zugriff.
Rechte ändern mit chmod
Der Befehl chmod (change mode) setzt die Berechtigungen. Du kannst ihn auf zwei Arten verwenden. In der oktalen Notation gibst du die Zielrechte direkt an: chmod 755 skript.sh oder chmod 644 dokument.txt. Diese Form ist eindeutig und bei Administratoren beliebt.
Die symbolische Notation ändert Rechte gezielt, ohne die anderen anzutasten. chmod +x skript.sh fügt das Ausführungsrecht für alle hinzu. chmod u+w datei gibt nur dem Owner (u) Schreibrecht, chmod go-r datei entzieht Gruppe (g) und Anderen (o) das Leserecht. Die Buchstaben stehen für u (user/owner), g (group), o (others) und a (all). Für Verzeichnisbäume fügst du -R hinzu, um rekursiv alle Unterordner zu erfassen – ein Befehl, der mit Bedacht einzusetzen ist.
Eigentümer ändern mit chown
Während chmod regelt, was erlaubt ist, bestimmt chown (change owner), wer Owner und Gruppe sind. sudo chown anna datei.txt macht den Benutzer „anna“ zum Eigentümer. Mit sudo chown anna:entwickler datei.txt setzt du Owner und Gruppe in einem Schritt. Das Ändern des Eigentümers erfordert fast immer Administratorrechte, also sudo.
Ein verwandter Befehl ist chgrp, der ausschließlich die Gruppenzugehörigkeit anpasst. In der Praxis ist die Kombination aus chown und Gruppen das Herzstück geteilter Projektverzeichnisse: Mehrere Benutzer gehören derselben Gruppe an und arbeiten gemeinsam an Dateien, während Außenstehende ausgeschlossen bleiben.
Warum richtige Rechte sicherheitsrelevant sind
Falsch gesetzte Berechtigungen sind eine der häufigsten Ursachen für Sicherheitslücken auf Servern. Eine Konfigurationsdatei mit Datenbankpasswörtern, die für alle lesbar ist, lädt jeden lokalen Nutzer zum Auslesen ein. Webserver-Verzeichnisse mit Schreibrechten für „Andere“ ermöglichen das Einschleusen von Schadcode. Die goldene Regel lautet daher: Vergib stets so wenige Rechte wie möglich und so viele wie nötig (Prinzip der minimalen Rechte).
Besonders kritisch sind Schlüsseldateien. SSH-Verbindungen verweigern den Dienst, wenn der private Schlüssel zu offene Rechte hat – ein bewusst eingebauter Schutz. Wenn du dich mit sicherer Serververwaltung beschäftigst, ist unser Artikel zu WireGuard VPN eine sinnvolle Ergänzung, und für starke Passwörter, die niemand erraten kann, hilft dir der Passwort-Generator.
Sonderrechte: setuid, setgid und Sticky Bit
Über die Standardrechte hinaus gibt es drei spezielle Bits, denen du in der Praxis begegnest:
- setuid: Ein Programm läuft mit den Rechten seines Owners statt mit denen des Aufrufenden. Der klassische Fall ist
passwd, mit dem normale Nutzer ihr Passwort ändern, obwohl die zugehörige Datei nur dem Administrator gehört. - setgid: Bei Verzeichnissen erben neu angelegte Dateien automatisch die Gruppe des Verzeichnisses – praktisch für gemeinsame Projektordner.
- Sticky Bit: In einem Verzeichnis mit Sticky Bit (typisch
/tmp) darf jeder Dateien anlegen, aber nur der jeweilige Owner seine eigenen löschen. Es verhindert, dass Nutzer sich gegenseitig Dateien wegnehmen.
Diese Sonderrechte erkennst du in der ls -l-Ausgabe an einem s oder t anstelle des gewohnten x. Du brauchst sie als Einsteiger selten selbst zu setzen, solltest sie aber lesen können, wenn sie dir begegnen.
Typische Stolperfallen
Drei Fehler tauchen immer wieder auf. Erstens: Ein Skript lässt sich nicht starten, weil das Ausführungsrecht fehlt – die Lösung ist fast immer chmod +x. Zweitens: Ein Verzeichnis ist trotz Leserechten unzugänglich, weil das Ausführungsrecht (das hier „betreten“ bedeutet) fehlt. Drittens: Die Versuchung, einem Problem mit chmod 777 zu begegnen. Dieser Befehl gibt jedem Nutzer alle Rechte und ist auf produktiven Systemen ein gravierendes Sicherheitsrisiko. Er ist fast nie die richtige Lösung – meist fehlt nur ein einzelnes, gezielt zu setzendes Recht.
Fazit
Das Linux-Berechtigungssystem ist elegant in seiner Einfachheit: drei Klassen, drei Rechte, ein paar Zahlen. Wer einmal verinnerlicht hat, dass 755 für ausführbare Dateien und 644 für Daten steht, löst die meisten Zugriffsprobleme intuitiv. Übe das Lesen der ls -l-Ausgabe, setze Rechte bewusst und greife nie aus Bequemlichkeit zu 777. Mit diesem Wissen verstehst du nicht nur das „Warum“ hinter „Permission denied“, sondern legst auch das Fundament für sichere Serveradministration.