![[Top Bar]](../../common/images/Topbar-en.gif){kind=small}
![[Bottom Bar]](../../common/images/Bottombar-en.gif){kind=small}
![[Photo of the Author]](../../common/images/Guido.2.gif)
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
|
![[Ilustration]](../../common/images/illustration40.gif)
Zusammenfassung
Dieser Artikel teilt sich in zwei Teile.
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
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 (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 |
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.
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 |