HomeMapIndexSearchNewsArchivesLinksAbout LF
[Top Bar]
[Bottom Bar]
[Photo of the Author]
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

[Ilustration]

Zusammenfassung Dieser Artikel teilt sich in zwei Teile.



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:

>id
uid=550(alice)  gid=100(users)  groups=100(users),6(disk)

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:

>ls -l   /usr/bin/id
-rwxr-xr-x    1 root   root    8632 May 9 1998 /usr/bin/id

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.

sst
421
(wird später
besprochen)
rwx
421
user
(Eignntümer)
rwx
421
group
(Gruppe)
rwx
421
others
(Andere)

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 a+w   file.txt
or
>chmod 666   file.txt
>ls -l   file.txt
-rw-rw-rw-   1 alice   users   79 Jan 1 16:14 file.txt

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:

>chmod 755   mydir
>ls -ld   mydir
drwxr-xr-x    2 alice    users    1024 Dec 31 22:32 mydir

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:

Die umask steht auf einem guten standardwert:
>umask
22

Nimm einen Editor und erzeuge eine Datei namens myscript:
>nedit   myscript   (or vi myscript ...)
schreib die folgenden Zeilen:

#!/bin/sh
#myscript
echo -n "hello "
whoami
echo "This file ( $0 ) has the following permissions:"
ls -l $0 | cut -f1 -d" "

Speichere das Script ab.
Jetzt hat es die Zugriffsrechte 644 (wegen umask):
>ls -l  myscript
-rw-r--r--   1 alice  users  108 Jan 1 myscript

Um das Script ausführen zu können, machen wir es ausführbar (executable):
>chmod 755 myscript
oder
>chmod a+x myscript

Jetzt können wir es laufen lassen:
>./myscript

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":

>ls -ld /usr/bin/crontab  /usr/bin/passwd  /usr/sbin/sendmail  /tmp

drwxrwxrwt   5 root   root   1024 Jan 1 17:21 /tmp
-rwsr-xr-x   1 root   root   0328 May 6 1998 /usr/bin/crontab
-r-sr-xr-x   1 root   bin     5613 Apr 27 1998 /usr/bin/passwd
-rwsr-sr-x   1 root   mail   89524 Dec 3 22:18 /usr/sbin/sendmail

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:

Alice erzeugt ein Verzeichnis, in dem das t-Bit gesetzt ist:
>mkdir mytmp
chmod 1777 mytmp


Nun legt Bob dort Dateien ab:
>ls -al
drwxrwxrwt   3 alice    users  1024 Jan  1 20:30 ./
-rw-r--r--  1 bob   users     0 Jan  1 20:31 f.txt

Diese Datei kann von Alice (Verzeichniseigentümer) und Bob (Dateieigentümer) gelöscht werden, jedoch nicht von Tux:

>whoami
tux
rm -f f.txt
rm: f.txt: Operation not permitted

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).


#!/bin/sh
#idinfo: Print user Information
echo " effective user-ID:"
id -un
echo " real user-ID:"
id -unr
echo " group ID:"
id -gn

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:

/*suidtest.c*/
#include <stdio.h>
#include <unistd.h>
int main(){
/*sichere SUID Programme dürfen
*auf keinen Fall auf Umgebungsvariablen oder Benutzereingaben vertrauen !! */

char *env[]={"PATH=/bin:/usr/bin",NULL};
char prog[]="/home/alice/idinfo";
if (access(prog,X_OK)){
    fprintf(stderr,"ERROR: %s not executable\n",prog);
    exit(1);
}
printf("running now %s ...\n",prog);
setreuid(geteuid(),geteuid());
execle(prog,(const char*)NULL,env);
perror("suidtest");

return(1);
}

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:

>chmod 4755   suidtest
or
>chmod u+s   suidtest

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:

>ls -l suidtest
-rwsr-xr-x   1 alice   users   4741 Jan 1 21:53 suidtest
>whoami
tux

running now /home/alice/idinfo ...
effective user-ID:
alice
real user-ID:
alice
group ID:
users

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:

>id
uid=550(alice)  gid=100(users)  groups=100(users),6(disk)

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:

>chmod 2775 .
>ls -ld .
drwxrwsr-x  3 tux   disk     1024 Jan 1 23:02 .

Wenn alice nun eine Datei in diesem Verzeichnis erzeugt, so gehört diese Datei zur Gruppe disk

>touch newfile
>ls -l newfile
-rw-r--r--   1 alice    disk      0 Jan 1 23:02 newfile

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).

Webpages maintained by Miguel Ángel Sepúlveda 
© Guido Socher 1998
LinuxFocus 1998