Guido Socher Über den Author:  Guido ist ein Linux-Fan, weil es ein freies Betriebssystem ist und es einfach Spaß macht, mit Leuten der Linux Gemeinde aus aller Welt zusammenzuarbeiten. Seine Freizeit verbringt er mit seiner Freundin, hört BBC World Service Radio, macht Fahrradtouren und arbeitet mit Linux. E-Mail an den Author  Inhalt: Einfache Dateizugriffsrechte T-bits, SUID und SGID

UNIX Dateizugriffsrechte

Zusammenfassung Dieser Artikel teilt sich in zwei Teile.

• Der erste Teil (Einfache Dateizugriffsrechte) ist eine kurze Einführung über Filezugriffsrechte unter UNIX.
• Der zweite Teil (T-bits, SUID und SGID) behandelt sehr fortgeschrittene Features von Linux, die über die einfachen "read-write-execute" Dateizugriffsbits hinausgehen.

Einfache Dateizugriffsrechte

Linux ist ein Multiuser Betriebssystem, bei dem individuelle Benutzer ihren Dateien unterschiedliche Zugriffsrechte zuweisen k�nnen. Jeder Benutzer hat eine Benutzerkennung (UID) und eine oder mehrere Gruppenkennung(en) (GID). Gruppenkennungen können benutzt werden, um Zugriffsrechte auf eine gewisse Anzahl (Gruppe) von Benutzern zu beschränken. Eine nette Sache, wenn man in einem Team gemeinsam arbeiten möchte und andere keine Zugriffsrechte haben sollen. Um seine Benutzerkennung und Gruppenkennung(en) herauszufinden, kann man einfach das Kommando id eintippen:

Zugriffsrechte können pro Datei gesetzt werden für Eigentümer (user), Gruppe (group) und andere (others) auf der Basis von Lese- (read) (r), Schreib- (write) (w) und Ausführrechten (execute) (x). Mit dem Kommando ls -l kann man diese Rechte anzeigen:

Die Datei /usr/bin/id gehört dem Eigentümer root und gehört zur Gruppe root.

Das -rwxr-xr-x zeigt die Dateizugriffsrechte. Diese Datei ist für den Eigentümer lesbar (readable), schreibbar (writable) und ausführbar (executable). Die Gruppe und alle anderen können die Datei lesen (read) und ausführen (execute).

Man kann sich diese Zugriffsrechte als einen Vektor von Bits vorstellen, wobei jeweils 3 Bits für Eigentümer, Gruppe und andere reserviert sind. r-x entspricht daher dem Bitmuster 101, oder in Dezimaldarstellung 4+1=5. Das r-Bit entspricht dezimal 4, das w-Bit dezimal 2 und das x-Bit dezimal 1.

Mit dem Kommando chmod kann man diese Zugriffsrechte ändern. Aus Sicherheitsgründen kann nur root oder der Eigentümer die Rechte von Files ändern. chmod nimmt als Argument entweder die dezimale oder eine symbolische Repräsentation. Die symbolische Darstellung ist [ugoa][+-][rwx]. Das ist einer der Buchstaben u (user=Eigentümer), g (group=Gruppe), o(others=Andere), a(all=alle=u und g und o) gefolgt von + oder -, um Rechte hinzuzufügen oder zu entfernen. Nach einem + oder - folgt die symbolische Darstellung der Rechte in Form von r(read=lesen), w(write=schreiben) und x(execute=ausführen). Um die Datei "file.txt" schreibbar für alle zu machen, tippt man das Kommando:

chmod 644 file.txt würde die Rechte wieder zurück auf "normal" setzen. 644 sind im allgemeinen die Standardrechte für gewöhnliche Dateien (lesen+schreiben für den Eigentümer und nur lesen für alle anderen).

In ein Verzeichnis mit dem Kommando cd zu wechseln, entspricht dem Ausführen (execute) der Verzeichnisdatei. "Normale" Zugriffsrechte für Verzeichnisse wären daher 755 und nicht 644:

Die Umask bestimmt den voreingestellten Standardwert (default permissions) für die Zugriffsrechte. Die Umask wird verwendet, wenn neue Dateien und Verzeichnisse angelegt werden. Als Argument nimmt umask den Dezimalwert der Bits, die man NICHT gesetzt haben möchte.

umask 022 ist z.B eine gute Wahl. Mit 022 kann jeder Deine Dateien lesen und in Verzeichnisse cd-en, aber nur Du selbst kannst Dateien anlegen und modifizieren. Um zu sehen, wie die Umask im Augenblick gesetzt ist, tippt man einfach umask ohne Argument.

Hier ein Beispiel, das zeigt wie umask und chmod benutzt werden:

Es ist zu beachten, daß ein Script (Batchdatei) ausführbar und lesbar sein muß um es laufen zu lassen. Ein normales Binärprogramm muß hingegen nur ausführbar sein. Der Grund dafür ist, daß das Script von dem Interpreter (shell) gelesen werden muß. Das obige Script sollte folgende Ausgabe erzeugen:

 
hello alice
This file ( ./myscript ) has the following permissions:
-rwxr-xr-x

T-bit, SUID und SGID

Nachdem man einige Zeit mit Linux gearbeitet hat, wird man vermutlich entdecken, daß es bei Dateizugriffrechten noch mehr als nur "rwx" gibt. Wenn man sich im Dateisystem umschaut, sieht man "s" und "t":

Was sind diese "s" und "t" Bits? Der Bit-Vektor, der die Dateizugriffsrechte beschreibt ist 4 * 3 Bits lang. chmod 755 ist daher nur eine Abkürzung für chmod 0755.

Das t-Bit

Das t-Bit (manchmal auch "sticky Bit" genannt) hat nur in Verbindung mit Verzeichnissen eine Bedeutung. Es wird z.B bei dem /tmp Verzeichnis benutzt.

Normalerweise (ohne t-Bit auf dem Verzeichnis) können Dateien von einer Person gelöscht werden, wenn die Person das Verzeichnis schreiben kann. Hat man also ein Verzeichnis, in dem jeder schreiben kann, so kann auch jeder die Dateien aller anderen löschen.

Das t-Bit ändert diese Regel. Ist das t-Bit für ein Verzeichnis gesetzt, so kann nur der Eigentümer der Datei (und der Verzeichniseigentümer) die Dateien löschen. Das t-Bit wird durch den Befehl chmod a+tw oder chmod 1777 gesetzt. Hier ist ein Beispiel:

S-Bit für den Eigentümer gesetzt

Unter Linux hat jeder Benutzer eine Kennung (user-ID). Diese Kennung ist wichtig für die Zugriffsrechte auf Resourcen (Dateien etc...). Es gibt 2 User-IDs. Die echte Kennung (real user-ID) und die wirksame Kennung (effective user-ID). Die effective User-ID bestimmt die Dateizugriffsrechte. Speichere das folgende Script unter dem Namen idinfo und ändere die Rechte auf ausführbar ((chmod 755 idinfo).

Wenn man das Script startet, sieht man, daß der Prozeß unter der User-ID und der Group-ID dessen läuft, der es gestartet hat:

 effective user-ID:
alice
 real user-ID:
alice
 group ID:
users

Wenn Tux das idinfo Programm laufen läßt, bekommt er eine ähnliche Ausgabe, nur daß man jetzt die IDs von Tux sieht. Die Ausgabe hängt also von der Person ab, die das Programm laufen läßt und nicht von der Person, der die Scriptdatei gehört (Eigentümer der Datei idinfo)

Aus Sicherheitsgründen ist das S-bint nur für Binärdateien (kompilierter Code) wirksam. Es funktioniert nicht für Scripts (Batchdateien), mit Ausnahme von perl-Scripts. Wir schreiben deshalb ein C-Programm, das das idinfo Script einfach aufruft:

Das Programm wird mit dem Befehlt "gcc -o suidtest -Wall suidtest.c" kompiliert, und anschließend kann man das S-Bit für den Eigentümer setzen:

Lassen wir es laufen! Was passiert? Nichts? Laß es unter einem anderen Benutzer laufen!

Die Eigentümerin der Datei suidtest ist Alice und in den Dateizugriffsrechten ist das S-Bit an der Stelle gesetzt, an der normalerweise das x (executable) für die Eigentümerin steht. Das S-Bit verursacht, daß diese Datei nun unter der Benutzerkennung dessen läuft, dem die Datei gehört, also nicht unter der ID des Benutzers, der das Programm startet. Wenn Tux das Programm ausführt, dann sieht das wie folgt aus:

Wie man sehen kann, ist das ein sehr mächtiges Feature, besonders wenn root die Datei gehört und das s-Bit gesetzt ist. Einige Worte über Sicherheit sind hier angebracht. Wenn man ein SUID-Programm schreibt, dann muß man sicherstellen, daß es wirklich nur für den Zweck benutzt werden kann, für den es bestimmt ist. Die PATH-Variable sollte immer auf einen festen Wert in dem Programm gesetzt werden. Man darf sich niemals auf Umgebungsvariablen verlassen und auch die Eingabe des Benutzers sowie Konfigurationsdateien muß man genau prüfen. Alle Eingaben (Benutzer oder Konfig-Datei) sollten Byte für Byte mit Werten verglichen werden, die man für korrekt hält.

Ein SUID-Programm, dessen Eigentümer root ist, kann sowohl die Effective- als auch die Real-UID setzen (mit der Funktion setreuid()).

Set-UID Programme werden oft benutzt, um dem normalen Benutzer Zugriff auf Dinge zu geben, die normalerweise nur von root gemacht werden können. Als root kann man z.B suidtest.c so modifizieren, daß jeder Benutzer damit die ppp-on/ppp-off Scripte laufen lassen kann.

S-Bit für die Gruppe gesetzt

Ausführbare Dateien, die das s-Bit auf die Gruppe gesetzt haben, laufen unter der Gruppen-ID des Dateieigentümers. Das ist analog zu dem, was wir oben gesehen haben, wenn das s-Bit auf den Eigentümer gesetzt war.

Eine etwas andere Bedeutung bekommt das s-Bit, wenn es auf dem Gruppenfeld eines Verzeichnisses gesetzt ist. In diesem Fall wird die Gruppe einer jeden Datei gesetzt, wenn diese Datei in dem Verzeichnis erzeugt wird. (Jedoch nur, wenn der erzeugende Benutzer auch in der Gruppe ist) Alice gehört zwei Gruppen an:

Ihre erste Gruppe ist users und normalerweise werden neue Dateien mit dieser Gruppe erzeugt. Gibt es jedoch ein Verzeichnis, das zur Gruppe disk gehört und das s-Bit im Gruppenfeld gesetzt hat, dann werden in diesem Verzeichnis neue Dateien mit der Gruppenzugehörigkeit disk erzeugt:

Das ist eine schöne Eigenschaft, wenn man mit einem Team an mehreren Dateien gemeinsam arbeiten möchte. Besonders in dem Fall, in dem aus Sicherheitsgründen die Dateien außerhalb einer Gruppe nicht gelesen werden können (die Leute haben eine 027 Umask).