 "Aufmacher Artikel")
Alles Recht
Sticky, SUID, SGID – Sonderrechte für Dateien und Verzeichnisse
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.
Kasten 1: Unterschied zwischen
rwxund
rwt
Im folgenden Beispiel meldet sich eine unprivilegierte Benutzerin mit su als root an. Mit root-Rechten erzeugt sie ein Verzeichnis namens bla mit dem Kommando mkdir und verleiht allen Usern Lese-, Schreib- und Ausführbarkeitsrechte für das neue Directory. In diesem Verzeichnis legt root mit dem Befehl touch eine (leere) neue Datei namens hallo an, die, wie ls -al zeigt, nur root schreiben darf.
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
Doch da die unprivilegierte Benutzerin Schreibrechte auf das Verzeichnis bla hat, darf sie hallo (auf Nachfrage) löschen, obwohl root ihr eigentlich keine Schreibrechte für diese Datei gegeben hat:
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
Hätte root das Verzeichnis bla hingegen mit dem Sticky Bit versehen …
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
… wäre das nicht passiert:
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).
Kasten 2: Verzeichnisse mit und ohne SGID-Bit
Die Benutzerin pjung kann als Mitglied mehrerer Gruppen auftreten. Wenn sie ein Verzeichnis (im Beispiel namens musik) anlegt, wird es automatisch ihrer Primärgruppe users zugeordnet.
pjung@linux:~> mkdir musik pjung@linux:~> ls -ald musik drwxr-xr-x 2 pjung users 4096 Okt 18 15:23 musik
Selbst wenn sie musik stattdessen der Gruppe audio "schenkt", ordnet das System darin angelegte Dateien wie wunsch.txt der Primärgruppe zu:
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
Erst, wenn das Verzeichnis musik das SGID-Bit erhält, gehören neuangelegte Dateien automatisch zur Gruppe audio. Die Besitzverhältnisse bereits bestehender Dateien ändern sich dadurch nicht:
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
Einem Freund empfehlen
