Wie Unix-Dateirechte funktionieren: 755 lesen, ohne zu raten

Drei Ziffern, drei Parteien — und nur eine greift

In der Ausgabe von `ls -l` steht an erster Stelle der Typ — ein Bindestrich für eine gewöhnliche Datei, d für ein Verzeichnis, l für einen symbolischen Link — und die folgenden neun Zeichen sind drei Dreiergruppen: Eigentümer, Gruppe, Andere. Überraschend ist, dass sie sich nicht summieren. Der Kernel nimmt die erste Klasse, zu der man gehört, und hört dort auf. Gehört dir eine Datei mit Modus 477, bekommst du r-- und sonst nichts, obwohl die Gruppen- und Anderen-Bits weit offen stehen: Die Eigentümerklasse traf zuerst zu, der Rest wird nie geprüft.

Es gibt zwei Schreibweisen für eine Änderung, und sie sind nicht gleichwertig. Oktal ist absolut: `chmod 644 notes.txt` setzt den gesamten Modus und löscht, was vorher da war. Symbolisch ist relativ: `chmod u+x script.sh` fügt ein Bit hinzu und lässt die anderen acht unberührt. In einem Deployment-Skript willst du fast immer die Oktalform, weil sie denselben Endzustand erzeugt, egal wie die Datei bei der Ankunft aussah.

Bei einem Verzeichnis ist das Ausführungsbit ein ganz anderes Recht

Nichts wird jemals ausgeführt, weil man einem Verzeichnis das x-Bit gibt. Bei einem Verzeichnis ist dieses Bit das Suchrecht: Es erlaubt einem Prozess, einen Namen darin aufzulösen und das Dahinterliegende zu erreichen. Der Unterschied ist leicht zu sehen. Setze ein Verzeichnis auf 400, und `ls` gibt die enthaltenen Namen bereitwillig aus, doch jede Abfrage scheitert und `cat dir/datei` wird abgelehnt — man sieht die Schilder und fasst nichts an. Setze es stattdessen auf 100, und es kehrt sich um: Auflisten geht nicht, aber wer den genauen Pfad schon kennt, öffnet die Datei. Diese Asymmetrie erklärt, warum ein Heimatverzeichnis mit 711 funktioniert: Andere erreichen ~/public_html, ohne den Rest aufzählen zu können.

Dieselbe Logik erklärt ein Ergebnis, das wie ein Fehler aussieht. Eine Datei zu löschen ist keine Änderung der Datei — es ist eine Änderung des Verzeichnisses, das sie auflistet. Über das Löschen entscheidet also Schreiben plus Ausführen auf dem enthaltenden Verzeichnis, und der Modus der Datei selbst spielt keine Rolle. Eine Datei mit 444 in einem Verzeichnis mit 777 kann jeder auf der Maschine löschen. Genau diese Lücke sollte das Sticky-Bit schließen, weshalb /tmp 1777 ist und nicht 0777.

Die vierte Ziffer, und warum umask kein Recht ist

Drei Sonderbits sitzen in einer optionalen führenden Ziffer. Setuid ist 4000: Bei einer ausführbaren Binärdatei läuft sie mit der Identität des Eigentümers — so bearbeitet passwd eine Datei, die du nicht anfassen darfst. Unter Linux wird es bei interpretierten Skripten stillschweigend ignoriert, und bei einem Verzeichnis hat es überhaupt keine Bedeutung. Setgid ist 2000: Bei einer Binärdatei tut es dasselbe für die Gruppe, bei einem Verzeichnis etwas weit Nützlicheres — neue Einträge erben die Gruppe des Verzeichnisses statt die des Erzeugers, und neue Unterverzeichnisse erben das Setgid-Bit ebenfalls, der Standardweg, um einen gemeinsamen Projektbaum konsistent zu halten. Sticky ist 1000: Bei einem Verzeichnis dürfen nur der Eigentümer des Eintrags, der Eigentümer des Verzeichnisses oder root löschen und umbenennen.

Umask ist das Stück, das am häufigsten verdreht wird. Es ist nicht das Recht, das neue Dateien bekommen — es ist eine Maske von Bits, die aus dem gelöscht werden, was das erzeugende Programm angefordert hat. Programme fordern 666 für eine Datei und 777 für ein Verzeichnis an, und jedes im umask gesetzte Bit wird abgeschaltet. Mit dem üblichen umask 022 bekommt man daher 644 für Dateien und 755 für Verzeichnisse. Und es löscht, statt zu subtrahieren: umask 023 ergibt bei einer neuen Datei weiterhin 644 und nicht 643, weil die Datei das Ausführungsbit nie angefordert hat und es nichts wegzunehmen gibt. Ein naher Verwandter: `chmod +x` ohne Klassenbuchstabe ist nicht dasselbe wie `chmod a+x`, denn die nackte Form berücksichtigt ebenfalls dein umask — unter umask 077 gewährt sie Ausführen nur dem Eigentümer.

Häufige Fragen

Warum ist chmod 777 die falsche Lösung?

Es gibt jedem Konto auf der Maschine Schreibzugriff, auch der Identität, unter der dein Webserver oder ein kompromittierter Prozess läuft — und weltweit schreibbarer Code ist Code, den jeder ersetzen kann. Außerdem geht es meist an der eigentlichen Ursache vorbei, die häufiger eine falsche Eigentümerschaft oder ein fehlendes Ausführungsbit an einem übergeordneten Verzeichnis ist als ein zu enges Recht. Manche Software verweigert schlicht die Zusammenarbeit: OpenSSH ignoriert einen privaten Schlüssel oder eine authorized_keys-Datei, die für Gruppe oder alle schreibbar ist.

Macht chmod 755 ein Skript lauffähig?

Es erteilt die Erlaubnis, es zu versuchen — das ist nicht dasselbe, wie es zum Laufen zu bringen. Eine Textdatei braucht zusätzlich eine Shebang-Zeile mit einem existierenden Interpreter, sonst hat der Kernel niemanden, dem er sie übergeben kann. Zwei Dinge stechen den Modus vollständig aus: Ein mit der Option noexec eingehängtes Dateisystem führt gar nichts aus, egal was die Bits sagen, und jedes Verzeichnis auf dem Weg zur Datei braucht sein eigenes Ausführungsbit, damit die Datei überhaupt erreichbar ist.

Warum kann jemand eine Datei löschen, die ich schreibgeschützt gesetzt habe?

Weil das Löschen eine Änderung des Verzeichnisses ist, nicht der Datei. Der Kernel prüft Schreiben und Ausführen auf dem Verzeichnis, das den Namen führt, und sieht sich den Modus der Datei nie an. Dagegen hilft, das Verzeichnis enger zu setzen oder ihm das Sticky-Bit zu geben, das Löschen und Umbenennen auf den Eigentümer des Eintrags, den Eigentümer des Verzeichnisses und root beschränkt — der Grund, warum ein gemeinsames /tmp 1777 ist.