Lese-, Schreib- und Ausführungsrecht: Soweit erklärt jedes Unix/Linux-Lehrbuch, was es mit Dateirechten auf sich hat. Doch es gibt noch mehr, zum Beispiel das berüchtigte SUID-Bit.

Eine der ersten Lektionen, die angehende Linuxer/innen lernen, ist die, dass sie Dateien und Verzeichnisse auf einem Multiuser-System nur dann benutzen können, wenn sie über entsprechende Rechte verfügen. Die Besitzerin (abgekürzt mit u für “user”) einer Datei hat welche, die Mitglieder der jeweiligen Eigentümergruppe (“group”) schmücken sich damit und alle anderen User auf dem System (“others”) auch. Wer sich ein File mit dem Befehl -al datei auf der Kommandozeile anschaut, sieht, wer damit was tun darf:

pjung@linux:~> ls -al /bin/ls
-rwxr-xr-x 1 root wheel 48832 Feb 17  2000 /bin/ls

Im Beispiel kann die Eigentümerin der Datei /bin/ls (namentlich root, wie das bei Systemprogrammen wie ls meist der Fall ist) jene lesen (“read”) schreiben (also verändern: “write”) und ausführen (“execute”). Auf dieses erste Rechtetripel rwx folgen die entsprechenden Angaben für alle Mitglieder der Gruppe wheel: Diese dürfen /bin/ls nicht verändern (statt eines w steht im mittleren Tripel ein -), aber durchaus lesen und ausführen. Selbiges gilt für alle übrigen User auf dem System, und das ist im Falle des letzten x-Bits auch gut so: Stünde an seiner Stelle ein -, könnten sich Normaluser nicht einmal über den Inhalt der eigenen Verzeichnisse informieren, da sich das ls-Kommando nicht aufrufen ließe.

Untersucht man Verzeichnisse auf Berechtigungen …

pjung@linux:~> ls -ald /home
drwxr-xr-x 55 root root 2048 Sep  2 13:08 /home

…, so gibt es auch hier keine Überraschungen. Nur die Bedeutung von rwx verschiebt sich ein wenig: r heißt reinschauen, w Dateien im Verzeichnis anlegen und x hineinwechseln dürfen. Das x-Recht braucht man grundsätzlich, um die im Verzeichnis befindlichen Dateien für Datei-Operationen zu öffnen.

Klebrige Verzeichnisse

Doch schon beim Anschauen des /tmp-Verzeichnisses

pjung@linux:~> ls -ald /tmp
drwxrwxrwt 11 root root 6144 Oct 18 13:50 /tmp

reicht dieses Wissen aus dem Einsteiger-Lehrbuch nicht mehr aus: Hier taucht plötzlich ein kleines t anstelle des Ausführungsrechts für “alle anderen” auf. Diese Sonder-Recht heißt “Sticky Bit”, und tatsächlich macht es Verzeichnisse klebrig: Darin befindliche Dateien dürfen nur von deren jeweiliger Besitzerin gelöscht werden, selbst wenn andere User Schreibrechte am Verzeichnis haben. Das Hineinwechsel-Recht für Verzeichnisse ist übrigens nicht verschwunden: ls zeigt nur dann ein kleines t anstelle des dritten x an, wenn jenes gesetzt wurde. Fehlt das x-Recht, wird aus dem kleinen ein großes T.

Allerdings können nichtprivilegierte Benutzer/innen in Verzeichnissen, in die sie nicht wechseln dürfen, weder Dateien ablegen noch rauslöschen. Stehen die Rechte auf rwxrwxrwT, haben lediglich die Besitzerin und die Eigentümergruppe des Verzeichnisses überhaupt die Möglichkeit, vom Sticky Bit zu profitieren.

Doch wozu das ganzes Theater mit dem Sticky Bit? Verzeichnisse wie das /tmp-Directory, in dem temporäre Daten abgelegt werden dürfen, sollten für sämtliche User des Systems schreibbar sein. Wenn aber alle darin Dateien anlegen können, dürfen bei einer Rechteverteilung von rwxrwxrwx auch alle sämtliche Files wieder löschen (Kasten 1), und das ist hier nicht erwünscht.

pjung@linux:~> su
Passwort: root-Passwort
# mkdir bla
# chmod a+rwx bla
# ls -ald bla
drwxrwxrwx    2 root     root         4096 Okt 18 14:09 bla
# touch bla/hallo
# ls -al bla/hallo
-rw-r--r--    1 root     root            0 Okt 18 14:09 bla/hallo
# exit

pjung@linux:~> rm bla/hallo
rm: schreibgeschützte Datei »bla/hallo« entfernen? y
pjung@linux:~> ls -al bla/hallo
ls: bla/hallo: Datei oder Verzeichnis nicht gefunden

pjung@linux:~> su
Passwort: root-Passwort
# chmod a+rwx,o+t bla
# ls -ald bla
drwxrwxrwt    2 root     root         4096 Okt 18 14:09 bla
# touch bla/hallo
# ls -al bla/hallo
-rw-r--r--    1 root     root            0 Okt 18 14:22 bla/hallo
# exit

pjung@linux:~> rm bla/hallo
rm: schreibgeschützte Datei »bla/hallo« entfernen? y
rm: Entfernen (unlink) von »bla/hallo« nicht möglich: Die Operation ist nicht erlaubt

Gruppenzwang

Doch nicht nur die dritte Stelle im Rechtetripel für “alle Anderen” lässt sich durch ein Zusatz-Recht modifizieren, sondern auch die im Eigentümerinnen- und Gruppen-Tripel. Kommt ein sogenanntes s-Bit zu den Rechten der Gruppe hinzu, hat das Folgen für alle Dateien, die in ein so gekennzeichnetes Verzeichnis hinein geschrieben werden: Egal, wer sie erzeugt, werden sie immer der Gruppe zugeordnet, der das Verzeichnis gehört. Dürfen Gruppenmitglieder nicht in ein solches Verzeichnis hineinwechseln, zeigt ls an dieser Stelle ein großes S statt eines kleinen an.

Auch hier steckt hinter der abstrakten Beschreibung ein konkretes Anwendungsziel: Fasst die Systemadministratorin mehrere User zu einer Arbeitsgruppe zusammen, so sollen die in der Regel gemeinsam auf Dateien zugreifen dürfen. Allerdings gehören die meisten User zusätzlich zu anderen Gruppen – sei es zu einer persönlichen Gruppe, die nur diesen einen User als Mitglied hat, oder zum Beispiel zur Gruppe users:

pjung@linux:~> groups
users uucp dialout audio video

Die erste Gruppe, die das Kommando groups ausgibt, ist die sogenannte Primärgruppe. Diese legt die Systemadminstratorin beim Erzeugen des User-Kontos fest; ihre Gruppen-ID (im Beispiel trägt users die Nummer 100) steht im passenden User-Eintrag der Datei /etc/passwd:

pjung@linux:~> grep pjung /etc/passwd
pjung:x:500:100:Patricia Jung:/home/pjung:/bin/bash

Über alle anderen Mitgliedschaften führt die Datei /etc/group Buch:

pjung@linux:~> grep pjung /etc/group
uucp:x:14:uucp,fax,root,fnet,pjung
dialout:x:16:root,pjung
audio:x:17:root,pjung
video:x:33:pjung

Legt ein User nun Dateien an, so sorgt das System dafür, dass sie seiner Primärgruppe zugeordnet werden. Möchte er sie stattdessen einer seiner anderen Gruppen zuteilen, muss er explizit das chgrp-Kommando bemühen. Das ist mühselig und in einer Arbeitsgruppe kaum durchzuhalten. Also versetzt die Administratorin das gemeinsame Oberverzeichnis einfach mit dem SGID-Bit (“Set Group ID”) und ist der Sorgen ledig (Kasten 2).

pjung@linux:~> mkdir musik
pjung@linux:~> ls -ald musik
drwxr-xr-x 2 pjung users  4096 Okt 18 15:23 musik

pjung@linux:~> chgrp audio musik
pjung@linux:~> ls -ald musik
drwxr-xr-x 2 pjung audio  4096 Okt 18 15:23 musik
pjung@linux:~> touch musik/wunsch.txt
pjung@linux:~> ls -al musik/wunsch.txt
-rw-r--r-- 1 pjung users     0 Okt 18 15:26 wunsch.txt

pjung@linux:~> chmod g+s musik
pjung@linux:~> ls -ald musik
drwxr-sr-x 2 pjung audio  4096 Okt 18 15:26 musik
pjung@linux:~> touch musik/inhalt.txt
pjung@linux:~> ls -l musik
insgesamt 0
-rw-r--r-- 1 pjung audio     0 Okt 18 15:29 inhalt.txt
-rw-r--r-- 1 pjung users     0 Okt 18 15:26 wunsch.txt

Unter falscher Flagge

Ausnahmsweise nicht auf Verzeichnisse, sondern ausschließlich auf ausführbare Dateien bezieht sich das SUID-Bit, also das s-Bit, das im Tripel der Eigentümerrechte gesetzt wird. Es sorgt dafür, dass Linux das entsprechende Programm nicht mit den Rechten des aufrufenden Users, sondern mit denen der Datei-Besitzerin ausführt. So läuft beispielsweise das passwd-Programm zum Ändern des Passworts effektiv immer mit root-Rechten, selbst wenn es von unprivilegierten Usern aufgerufen wird:

pjung@linux:~> ls -al /usr/bin/passwd
-r-sr-xr-x 1 root bin   8735 Feb 17  2000 /usr/bin/passwd

Der Grund: Beim Setzen des Passworts muss die Passwortdatei geändert werden. Diese darf aber nicht für alle Welt schreibbar sein, sonst wäre dem Schabernack mit fremden Passwörtern Tür und Tor geöffnet. Liefe das passwd-Programm hingegen wie üblich mit den Rechten der Aufrufenden, so kann es natürlich nur Dateien ändern, für die diese Benutzerin Schreibrechte hat, also sicher nicht die Passwortdatei. Aus dem Dilemma hilft das SUID-Bit: Das passwd-Programm bekommt für die Dauer seiner Tätigkeit root-Rechte und darf somit das Passwort austauschen.

Abbildung 1: Konqueror verschweigt das SUID-Bit in der Ballon-Hilfe – erst der “Eigenschaften”-Dialog aus dem Kontextmenü klärt auf

Doch so hilfreich das SUID-Bit ist, so gefährlich ist es auch: Wenn ein mit SUID-Rechten laufendes Programm nicht sauber programmiert ist, bietet es Hackern u. U. Angriffsmöglichkeiten. Im schlimmsten Fall heißt das, dass der unter Fremdrechten laufende Prozess weitere Programme mit den privilegierteren Rechten ausführt und/oder dem aufrufenden User eigentlich nicht zugängliche Dateien manipuliert. Deshalb ist es aus Sicherheitsgründen angeraten, das SUID-Bit sehr sparsam zu vergeben. Bei Shell-Skripten wirkt es vorsichtshalber gar nicht.

Was mit User-Berechtigungen geht, funktioniert auch bei Gruppen: Setzt man das SGID-Bit für ausführbare Dateien, laufen entsprechende Prozesse “im Namen” der Besitzergruppe, also effektiv mit deren Rechten. Voraussetzung ist nur, dass der aufrufende User die Datei auch ausführen darf.

Sonderrechte einräumen

Ob nun rwx oder s und t – Rechte vergibt oder entzieht das Kommando chmod (change mode). Wie bei den Lese-, Schreib- und Ausführbarkeitsrechten geht das mit den arithmetischen Operationen +, - und =: chmod u-s programmdatei entfernt das SUID-Recht von einem Programm, chmod g+xs verzeichnis verteilt das SGID-Bit gleichzeitig mit dem Verzeichniswechselrecht für die Inhabergruppe und chmod o=rwxt verzeichnis setzt das für alle anderen User gedachte Rechtetripel auf rwt.

Fehlt dem Sonderrecht das “darunterliegende” x-Bit, macht ls dies durch einen Großbuchstaben S bzw. T an der entsprechenden Stelle deutlich.

Natürlich lassen sich die Spezialrechte auch in Oktalschreibweise setzen. So wie dem Leserecht r der Wert 4, dem Schreibrecht w der Wert 2 und dem x-Bit die 1 zugeordnet sind, bekommen auch sie Zahlen-Äquivalente:

• 1 für das t-Bit (Sticky Bit),
• 2 für das SGID-Bit und
• 4 für das SUID-Bit.

Damit sich diese nicht mit rwx beißen, addiert man sie nicht etwa zur Summe der Eigentümer-, Gruppen- oder Anderen-Rechte hinzu, sondern summiert sie in einem eigenen, vierten Wert zusammen: chmod 1777 verzeichnis sorgt genauso wie chmod u,g=rwx,o=rwxt dafür, dass verzeichnis die Rechte rwxrwxrwt bekommt: Die erste Ziffer steht für die Summe der Sonderrechte, hier also 1 für t, die zweite zählt die “normalen” Rechte der Eigentümerin zusammen (r+w+x=4+2+1=7), die dritte die der Gruppe und die letzte die der Anderen. Soll das Verzeichnis noch das SGID-Bit hinzubekommen (rwxrwsrwt), lautet der Befehl chmod 3777 verzeichnis. Die oben aufgelisteten Rechte von /usr/bin/passwd hingegen (r-sr-xr-x) wurden sicher einmal mit chmod 4555 /usr/bin/passwd gesetzt.