Linux besitzt eine recht einfache und durchschaubare Rechteverwaltung.
Genau genommen gibt es nur zwei User, root und den Rest.
Der Administrator root besitzt im Prinzip jedes Recht oder kann es sich verschaffen.
Für alle anderen User werden die Dateirechte durch die Rechteverwaltung geregelt.
Abgesehen von besonderen Rechten wie SetUID, SetGID, sticky, acl u.ä, auf die ich an anderer Stelle noch eingehen werde, sieht die Rechteverwaltung so aus:
drwxr-xr-x | 4 | frank | frank | 4096 Aug 17 11:52 | . |
drwxrwxrwt | 19 | root | root | 4096 Aug 17 11:15 | .. |
-rw-r--r-- | 1 | frank | frank | 17 Aug 17 11:50 | Datei1 |
-rw-rw-rw- | 1 | frank | users | 10 Aug 17 11:52 | Datei2 |
-rw-r--r-- | 1 | frank | frank | 16 Aug 17 11:52 | Datei3 |
drwxr-xr-x | 2 | frank | frank | 4096 Aug 17 11:51 | Ordner1 |
drwxr-xr-- | 2 | root | root | 4096 Aug 17 11:51 | Ordner2 |
-rw-r----- | 1 | root | root | 6 Aug 17 11:50 | TEST |
Diese Ausgabe zeigt nun die wichtigsten Angaben zu Besitzern und Rechten.
1.Abschnitt (gelb unterlegt)
Im gelb unterlegten Teil zeigt das erste Zeichen den Dateityp an.
Die dort angezeigten Zeichen haben folgende Bedeutungen:
Zeichen | Bedeutung |
- | es handelt sich um eine reguläre Datei, also um einen Hardlink auf eine echte Datendatei oder um eine Pseudodatei (z.B. in /proc) |
d | es handelt sich um ein Verzeichnis (directory), also um einen Hardlink auf eine Verzeichnis oder um eine Pseudodatei (z.B. in /proc) |
l | es handelt sich um einen Softlink, also einen symbolischen Verweis auf eine andere Datei oder ein Verzeichnis |
c | es handelt sich um die Gerätedatei eines zeichenorientierten Gerätes, das ist eine Pseudodatei des Kernels (z.B. /dev/console |
b | es handelt sich um die Gerätedatei eines blockorientierten Gerätes, das ist eine Pseudodatei des Kernels (z.B. /dev/sda |
p | es handelt sich um eine Named Pipe, das ist eine Pseudodatei, die als FIFO dient |
Danach folgen drei Gruppen von Rechten, also neun Zeichen.
Die ersten drei Zeichen der Gruppe zeigen die Rechte, die der Eigentümer der Datei besitzt.
Die Angabe rwx bedeutet, dass er das Schreibrecht r, das Leserecht w und das Ausführungsrecht x besitzt.
Ist eines der Rechte nicht gewährt, dann befindet sich an der Stelle ein Strich -.
Die nächsten drei Zeichen der Gruppe zeigen die Rechte an, die alle User besitzen, die der Gruppe angehören, die der Datei zugeordnet wurde.
Die dritte Dreiergruppe zeigt die Rechte für alle anderen User des Systems an.
Die Rechte rwx haben im Einzelnen folgende Bedeutung;
Schaut man sich die Ausgabe insgesamt an, dann fällt zuerst auf, dass zuerst zwei Verzeichnisse . und .. aufgelistet werden.
Dabei handelt es sich um besondere Dateien.
Die Datei . ist ein Hardlink auf dieses Verzeichnis selbst.
Die Datei .. ist ein Hardlink auf das übergeordnete Verzeichnis.
Diese beiden Links sind z.B. wichtig für die relativen Dateipfade.
Die Zeile
drwxr-xr-x 4 frank frank 4096 Aug 17 11:52 .
sagt jetzt also aus, dass User frank, also ich, der Besitzer dieses Verzeichnisses ist und als Gruppe die Gruppe frank eingetragen ist.
Der Besitzer frank hat die Rechte rwx, er darf das Verzeichnis auslesen (r), Dateien anlegen, löschen und umbenennen (w) und er darf in das Verzeichnis wechseln (x).
Die User in der Gruppe frank und alle anderen User haben die Rechte r-x, sie dürfen sich den Verzeichnisinhalt auslesen (r) und in das Verzeichnis wechseln (x).
Durch das fehlende Schreibrecht können die anderen User des Systems (ausgenommen natürlich root) keine Dateien in diesem Verzeichnis anlegen, umbenennen oder löschen.
Achtung! Das fehlende Schreibrecht bedeutet nur, dass die anderen User nur dieses Verzeichnis nicht verändern können.
Es ist trotzdem noch möglich, dass andere User Dateien oder Unterverzeichnisse in diesem Verzeichnis verändern können.
Der Schreibschutz des Verzeichnisses wird nicht an Unterverzeichnisse vererbt und auch nicht auf die Inhalte der Dateien in dem Verzeichnis übertragen.
Jede Datei regelt den Zugriff auf ihren Inhalt immer über die eigenen Dateirechte!!
Das gilt z.B. für die Datei Datei2:
-rw-rw-rw- 1 frank users 10 Aug 17 11:52 Datei2
Für diese Datei besitzen alle User des Systems ein Schreibrecht.
Sie können diese Datei zwar nicht löschen, also aus dem Verzeichnisbaum entfernen, denn ihnen fehlt das Schreibrecht auf das Verzeichnis, aber da sie das Schreibrecht auf die Datei besitzen, können sie die Datei mit neuem Inhalt füllen oder z.B. mit echo -n > Datei2 einfach leeren.
Die Datei ist dann zwar noch da, besitzt aber keinen Inhalt mehr.
Ähnlich liegt der Fall bei der Datei TEST
-rw-r----- 1 root root 6 Aug 17 11:50 TEST
Der Besitzer der Datei ist root, er darf den Dateiinhalt lesen und schreiben (rw-), die User in der Gruppe root dürfen nur lesen.
Da ich als User Frank nicht root bin und auch kein Mitglied der Gruppe root, trifft auf mich das other-Recht zu und alle anderen User haben keine Rechte auf den Inhalt der Datei.
Ich kann den Inhalt der Datei also nicht lesen, geschweige denn überschreiben, aber ich darf sie löschen!
Ich als User frank bin Besitzer des Verzeichnisses und habe ein Schreibrecht darauf und deshalb darf ich eine Datei des Administrators root, der mir alle Rechte auf den Inhalt der Datei entzogen hat, löschen.
Die Bash fragt zwar vorher noch einmal nach, ob ich die schreibgeschützte Datei wirklich löschen will, da ich will ist sie dann auch gelöscht.
bash-4.1$ ls -al insgesamt 32 drwxr-xr-x 4 frank frank 4096 Aug 17 11:52 . drwxrwxrwt 19 root root 4096 Aug 17 11:15 .. -rw-r--r-- 1 frank frank 17 Aug 17 11:50 Datei1 -rw-rw-rw- 1 frank users 10 Aug 17 11:52 Datei2 -rw-r--r-- 1 frank frank 16 Aug 17 11:52 Datei3 drwxr-xr-x 2 frank frank 4096 Aug 17 11:51 Ordner1 drwxr-xr-- 2 root root 4096 Aug 17 11:51 Ordner2 -rw-r----- 1 root root 6 Aug 17 11:50 TEST bash-4.1$ rm TEST rm: reguläre Datei (schreibgeschützt) »TEST« entfernen? y bash-4.1$ ls -al insgesamt 28 drwxr-xr-x 4 frank frank 4096 Aug 17 14:17 . drwxrwxrwt 19 root root 4096 Aug 17 11:15 .. -rw-r--r-- 1 frank frank 17 Aug 17 11:50 Datei1 -rw-rw-rw- 1 frank users 10 Aug 17 11:52 Datei2 -rw-r--r-- 1 frank frank 16 Aug 17 11:52 Datei3 drwxr-xr-x 2 frank frank 4096 Aug 17 11:51 Ordner1 drwxr-xr-- 2 root root 4096 Aug 17 11:51 Ordner2 bash-4.1$
Dieses Verhalten kann durch Vergabe von Sonderrechten modifiziert werden. Es ist z.B. sinnvoll wenn in gemeinsam genutzten Verzeichnissen ein gewisser Konsens über vergebene Rechte und Besitzer herrscht, um den gemeinsamen Zugriff und den Datenaustausch zwischen mehreren Usern zu erleichtern. Siehe dazu den Abschnitt Sonderrechte.
In diesem Zusammenhang möchte ich auf den besonders bescheuerten Tipp "Setz die Rechte des Verzeichnises auf 777" hinweisen, der oftmals in Foren auftaucht. Der Tipp wird vergeben, wenn Honks irgendeine Daddel-Applikation auf einem frisch gemieteten Root-Server installieren wollen oder irgendein PHP-Script Dateien schreiben soll. 777 bedeutet rwxrwxrwx, also alle besitzen volles Schreibrecht auf das Verzeichnis!! Das bedeutet, jeder hat Vollzugriff auf das Verzeichnis und kann es löschen oder eigene Dateien dort einschleusen und eventuell ausführen!!! Wenn es sich bei der Maschine um einen Rechner mit Internetanbindung handelt, bedeutet jeder unter Umständen wirklich JEDER!
Die Dateirechte können grundsätzlich nur von dem Besitzer der Datei und von root geändert werden.
Dazu dient das Kommando chmod (change mod).
Ich selbst benutze gern die oktale Schreibweise, da sie aus meiner Sicht eine schnelle Möglichkeit ist um alle Rechteeinstellungen vorzunehmen.
Dabei werden die einzelnen Rechte mit Bit-Werten eingestellt. Bit 0 bedeutet, das recht wird verweigert und Bit 1 bedeutet das Recht wird erteilt.
Die einzelnen Bits sind so wie in der Tabelle angegeben angeordnet und werden dann als Oktalzahl notiert.
Im Beispiel soll der Besitzer der Datei NAME alle Rechte rwx, die Teilnehmer der Gruppe nur rx und alle anderen User keine Rechte an der Datei erhalten.
Die Oktalwerte ergeben sich dann, indem die Wertigkeiten der vergebenen Rechte in den Dreiergruppen zusammenaddiert werden.
Rechtegruppe | Sonderrechte | Benutzerrechte | Gruppenrechte | Other-Rechte | ||||||||
Bedeutung | Set-UID | Set-GID | Stiky | r | w | x | r | w | x | r | w | x |
Wertigkeit | 4 | 2 | 1 | 4 | 2 | 1 | 4 | 2 | 1 | 4 | 2 | 1 |
Beispiel | 0 | 0 | 0 | 4 | 2 | 1 | 4 | 0 | 1 | 0 | 0 | 0 |
0+0+0 0 |
4+2+1 7 |
4+0+1 5 |
0+0+0 0 |
Der Befehl lautet also:
chmod 0750 NAME
Will man nur die echte bestimmter Gruppen verändern, so ist die symbolische Schreibweise günstiger.
Der Besitzer wird festgelegt, wenn die Datei erzeugt wird. Der Prozess, also z.B. die Shell die die Datei erzeugt, läuft mit einer bestimmten User-ID und dieser User wird als Besitzer eingetragen. Eine Änderung des Besitzers ist nur mit root-Rechten mit dem Kommando chown (change owner) möglich, allen anderen Usern ist es nicht gestattet, den Besitzer einer Datei zu verändern. Das ist auch sinnvoll, damit nicht ein User z.B, einem anderen User oder gar root eine Datei unterschieben kann. Von Besitzer A kann eine Datei X nur an den Besitzer B übergehen, wenn A mit chmod ein Leserecht für B einräumt und B sich eine Kopie, z.B. mit cp anfertigt. Für diese Kopie ist dann B der Besitzer.
Den Gruppeneintrag kann der Besitzer der Datei (und root) z.B. mit dem Kommando chgrp (change group) ändern. Der Besitzer kann den Gruppeneitrag aber nur auf Gruppen einstellen, in denen er selbst Mitglied ist. Auskunft darüber gibt das Kommando id.
Diese drei Bits räen bestimmte Sonderrechte auf Dateien ein. In der Urzeit der Unix-Systeme gab es diese Bits, außer dem Set-UID noch nicht und deshalb ist die Reaktion der Systeme auch nicht einheitlich. Im Einzelfall muss man also in die Dokumentationen schauen oder ausprobieren. Ich will hier nun kurz beschreiben, wie mein System reagiert.
Ein gesetztes Set-UID bewirkt, dass die Datei mit den Rechten des Besitzers der Datei ausgeführt wird und nicht mit den Rechten des Users, der die Datei aufgerufen hat.
Im Normalfall wird ein Prozess immer mit der UID des Users ausgeführt, der den Prozess gestartet hat.
Manchmal ist es aber notwendig, dass auch ein Normaluser auf Komponenten zugreifen muss, für die er keine Berechtigung besitzt.
Ein Beispiel dafür ist z.B. der Befehl mount:
bash-4.1$ ls -al /bin/mount
-rwsr-xr-x 1 root root 64180 Feb 16 2011 /bin/mount
Das kleine s bei den Besitzerrechten zeigt an, dass die Datei ein Ausführungsrecht (x) mit einem Set-UID (s) besitzt.
Alle anderen User des Systems besitzen ebenfalls ein Ausführungsrecht (Gruppe root r-x und Other r-x).
Startet nun ein anderer User dieses Kommando, dann wird es mit root-Rechten ausgeführt.
Der User kann mit diesem Kommando also Aktionen ausführen, die eigentlich nur root zustehen.
Ein solches Set-UID darf also nicht leichtfertig vergeben werden und die Programme mit solch einem Set-UID müssen sehr gewissenhaft programmiert sein und genau unterscheiden, wer es gerade benutzt.
Es muss also sichergestellt werden, dass der User nur einen eingeschränkten Funktionsumfang mit starken Restriktionen nutzen kann.
Achtung! Aus Sicherheitsgründen ist ein auf Scripte vergebenes Set-UID grundsätzlich wirkungslos.
Für Set-GID gilt im Prinzip das selbe wie für Set-UID. Die Datei wird nur mit dem Ausführungsrecht der Gruppe gestartet.
Soweit mir bekannt ist, hat das Sticky-Bit für ausführbare Dateien heute keine Bedeutung mehr und wird von den meisten Systemen ignoriert.
Ein gesetztes Set-UID wird auf vielen Systemen aus Sicherheitsgründen ignoriert. Es würde die Beschränkungen des chown zu stark aushebeln. Es soll bewirken, dass die UID des Besitzers des Verzeichnisses sich auf die im Verzeichnis angelegten Dateien und Unterverzeichnisse vererbt.
Ein gesetztes Set-GID auf ein Verzeichnis bewirkt, dass sich der Gruppeneneintrag auf alle im Verzeichnis angelegten Dateien und Unterverzeichnisse vererbt. Alle Dateien und Unterverzeichnisse gehören damit der selben Gruppe an, wie das Verzeichnis selbst. Das Set-GID vererbt sich auch automatisch auf alle Unterverzeichnisse. Diese Einstellung erleichtert den Usern die Arbeit in gemeinsam genutzten Verzeichnissen, da so leichter Daten ausgetauscht werden köen.
Ein gesetztes Stiky-Bit bewirkt, dass User die Dateien anderer User in gemeinsam genutzten Verzeichnissen nicht gegenseitig löschen können. Ein Beispiel dafür ist das Verzeichnis /tmp in das grundsätzlich alle User schreiben dürfen. Durch ein Schreibrecht auf das Verzeichnis hätten sie grundsätlich die Möglichkeit, die Dateien anderer User zu löschen. Das wird durch das gesetzte Sticky-Bit verhindert.