Zugriffsrechte

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

Robi 23:23, 20. Okt 2006 (CEST)

Die Zugriffsrechte unter Linux/Unix sind im Grunde recht einfach aufgebaut. Einfach heißt hier aber auf keinen Fall wenig wirkungsvoll und wenig variabel. Der prinzipielle Aufbau und die Anwendung der Zugriffsrechte auf Dateien gehört zum absolutem Grundwissen für alle, die sich mit Linux beschäftigen und sollte daher im Schlaf beherrscht werden. Zugriffsrechte besitzen aber nicht nur Dateien, sondern auch Prozesse. Die Zugriffsrechte der Prozesse sind vom Grundprinzip ähnlich, wenn auch in der Gesamtheit etwas komplizierter aufgebaut, wie die Zugriffsrechte auf Dateien.

Aufbau der Zugriffsrechten für Dateien

Jede einzelne Datei in einem Linux oder UNIX-System - also nicht nur normale Dateien sondern auch Verzeichnisse, Gerätedateien, Pipes und Sockets besitzen in ihrer Inode neben der Kennung zum Dateitype und verschiedene Zeitstempel auch zwingend die Einträge über die Eigentumsrechte und Zugriffsrechte auf die Datei. Die Eigentumsverhältisse einer Datei sind spezifiziert in genau einem Eigentümer und genau einer Benutzergruppe. Die Zugriffsrechte sind 3 teilig gestaffelt und beziehen sich auf

• Eigentümer (User) genau dieser Datei
• Gruppenmitglieder (Gruppe) Angehörige der Gruppe genau dieser Datei
• alle Anderen die nicht User oder Gruppe sind also auf den Rest der Welt (Andere)

User haben genau eine Primäre Gruppe, können aber zusätzlich noch mehreren Sekundären Gruppen angehören. Für die Gruppen-Zugriffsrechte auf die Dateien ist es nicht von Bedeutung ob der User primär oder sekundär über die Gruppenrechte verfügt.

Der Befehl ls -l Dateiname zeigt für jede einzelne Datei die Angaben über Besitz und Zugriffsrechte

-rw-rw-r--   1 otto     wiki         1916 Jul 29  2006 ftp.wiki

Das erste Zeichen der Ausgabe der Zugriffsrechte mittels ls zeigt, um was für eine Datei es sich handelt. Folgende Dateiarten sind definiert:

-	Reguläre (normale) Datei
d	Verzeichnis (directory)
l	Symbolischer Link (symlink)
b	Blockorientierte Gerätedatei (block device)
c	Zeichenorientierte Gerätedatei (character device)
p	Feste Programmverbindung (named pipe)
s	Netzwerk Kommunikationsendpunkt (socket)

Dem ersten Zeichen folgende 9 Zeichen sind die genaue Beschreibung der Zugriffsrechte.

• die ersten drei Zeichen beschreiben die Rechte des Eigentümers der Datei
• die nächsten drei die Rechte eines Gruppenmitglieds der Gruppe
• die letzten drei die Rechte aller Anderen

Für diese drei Kategorien (User, Gruppe, Andere) existiert jeweils die Angabe über die Berechtigung zum

• lesen (read -> r)
• schreiben (Write -> w )
• ausführen (execute -> x)

Das obrige Beispiel bedeutet also:

-rw-rw-r-- 	die Datei ftp.wiki ist eine normale Datei 
otto 		der Eigentümer ist User otto
wiki 		die Gruppe ist wiki
-rw-rw-r-- 	User otto darf diese Datei lesen und schreiben
-rw-rw-r-- 	User die der Gruppe wiki angehören dürfen die Datei lesen und schreiben
-rw-rw-r-- 	Alle anderen dürfen diese Datei nur lesen

Octale Zuweisung der Zugriffsrechte

Diese Rechte können numerisch (octal) dargestellt werden. Dazu werden die Rechte wie folgt bezeichnet:

Octale Zuordnung der Zugriffsrechte

User			Gruppe			Rest
r	w	x	r	w	x	r	w	x
4	2	1	4	2	1	4	2	1

Die Nummern werden für jede der drei Kategorien einzeln addiert. Ein Zugriffsrecht von rwxrw-r-- wäre so also numerisch darstellbar als 764.

• die 7 errechnet sich aus dem r (4) + w (2) + x (1) des Eigentümers
• die 6 aus dem r (4) + w (2) + - (0) für die Gruppenmitglieder
• die 4 stammt vom r (4) + 0 + 0 für den Rest der Welt

Interpretation der Zugriffsrechte

normale Dateien

Für normale (reguläre) Dateien sind diese Rechte recht einfach zu interpretieren.

• Leserecht bedeutet, der Inhalt der Datei kann gelesen und damit zB auch durchsucht werden.
• Schreibrecht bedeutet, daß der Inhalt der Datei darf verändert werden. Somit kann zB eine Datei erweitert und verändert aber auch eine Datei auf Länge Null, also Leer geändert werden (Inhalt gelöscht)
• Ausführungsrecht bedeutet, diese Datei kann, sollte es sich um ein Script oder ein Executabel Binär Programm handeln, ausgeführt werden, dazu ist jedoch bei Scripten zusätzlich noch Leserecht erforderlich. (Leserecht wird normaler weise auch für ausführbare Binarprogramme gewährt, damit kann dann jeder User zB. mit dem Befehl file feststellen, um welchen Dateitype es sich handelt oder mit ldd welche shared Librarys zur Ausführung benötigt werden)

Verzeichnisse

Bei Verzeichnissen ist es besonders für den Linuxneuling schwieriger zu verstehen. Die andere Interpretation ist begründet im Aufbau der Verzeichnisdateien, die im Grunde genommen nur normale Textdateien sind, in denen in einer Art Tabelle jeweils ein Dateiname einer Inodenummer zugeordnet ist. Bei Verzeichnissen bedeutet:

• Leserecht, der Inhalt dieses Verzeichnisses darf aufgelistet werden, (also die Dateinamen dürfen gelesen werden)
• Schreibrecht, Dateien dürfen im Verzeichnis angelegt, umbenannt und gelöscht werden, (Dateinamen dürfen verändert werden)
• Ausführungsrecht, in das Verzeichnis darf gewechselt (betreten) werden

Dieses zeigt, die Zugriffsrechte der Verzeichnisse sind ebenso wichtig, wie die Zugriffsrechte auf die Dateien selbst. ZB kann wer Schreibrechte in einem Verzeichnis hat, dort auch jede Datei löschen, auch wenn er für diese Dateien sonst überhaupt keine Rechte hat. Wer aber nur das Schreibrecht auf eine Datei hat, aber nicht das Schreibrecht im Verzeichniss, kann zwar in einer Datei Zeilen oder den gesammten Inhalt löschen, den Dateinamen mit dessen Bezug auf die Inode allerdings nicht.

Symbolische Links

Symbolische Links haben immer alle Zugriffsrechte also numerisch 777 und dieses läßt sich auch nicht ändern. Der Zugriff auf Dateien die so verlinkt sind wird damit einzig durch die Zugriffsrechte der eigentlichen Datei bestimmt.

Hard Links

Da Hard Links logisch gesehen nur ein weiterer Name für ein und die selbe Inode sind, die Zugriffsrechte jedoch in der Inode gespeichert sind, können Hardlinks niemals unterschiedliche Besitz oder Zugriffsrechte haben.

Spezielle Rechte

Neben diesen 3x3 Rechten existieren noch drei weitere, die sich numerisch als weitere (führende) Octalziffer darstellt. Dabei handelt es sich um das Substitute UserID Bit (4), das Substitute GroupID Bit (2) und das Sticky Bit (1).

Substitute UserID Bit (SUID)

Dieses Recht gilt ausschließlich für ausführbare Dateien. ( in modernen Linuxsystemen nicht für Scripte ) Hat eine ausführbare Datei dieses Recht gesetzt, so erscheint in der Darstellung durch das ls -l Kommando statt dem x beim Eigentümerrecht ein s. Wird dieses Programm von einem User ausgeführt, bekommt der Prozess die effektive UserID des Users, dem die Datei gehört und nicht wie normal die UserID des Users der das Programm ausführt. Sollte diese Recht gesetzt werden, ohne das auch das Ausführungsrecht des Eigentümers gesetzt ist, erscheint hier ein S, dieses deutet auf logisch unvollständig gesetzte Ausführungsrechte hin.

Das klassische Beispiel: das Programm /usr/bin/passwd hat die Aufgabe, daß auch normale User damit ihr eigenes Passwort ändern können. Dieses Passwort befindet sich jedoch in einer Datei, die nur von root selbst beschrieben werden darf. Somit hat das Programm /usr/bin/passwd deren Eigentümer root ist, das Substitute UserID Bit gesetzt. Jeder User, der dieses Programm ausführt tut dies jetzt also unter der effektiven UserID von root und hat daher die Rechte von root mit diesem einem Prozess. Das ermöglicht es dem Programm, das Passwort auch zu wirklich zu ändern.

Das ist beim Passwort-Programm nicht problematisch, jedoch können mit diesem Zugriffsrecht richtige Sicherheitslücken entsteht, wenn zB eine Shell mit diesem Bit ausgestattet würde und der Eigentümer root ist, hätte jeder User mit dieser Shell uneingeschränktes Rootrecht. Es gehört zu den Aufgaben des Systemadministrators das System regelmäßig nach derart riskant gesetzten SUID-Bits oder riskanten Kombinationen mit Schreibrechten auf diese Dateien zu durchsuchen.

Substitute GroupID Bit (SGID)

bei normalen ausführbaren Dateien

Dieses Recht gilt einerseits für ausführbare Dateien und andererseits für Verzeichnisse. Hat ein ausführbares Programm dieses Recht gesetzt, so gilt das Gleiche, wie beim Substitute UserID Bit, diesmal betrifft es aber die effektive Gruppenmitgleidschaft des Prozesses. Der Prozess bekommt während der Laufzeit die effektive GruppenID der Gruppe, der dieses Programm zugeordnet ist, anstatt seiner eigentlichen GruppenID. Er hat also die Rechte eines Gruppenmitglieds dieser Gruppe, auch wenn er selbst nicht Mitglied in dieser Gruppe ist. Statt dem x beim Gruppenrecht stellt das ls -l Kommando hier ein s dar. Es gilt ebenfalls, sollte das Ausführungsrecht der Gruppe nicht gesetzt sein, erscheint ein S und deutet auf logisch unvollständig gesetzte Berechtigungen hin. Auch diese SGID-Bit sollte im Linux-System unter regelmäßiger Beobachtung des Administrators stehen.

bei Verzeichnissen

Ist dieses Recht auf ein Verzeichnis gesetzt, bewirkt es etwas ganz anders. Legt ein User, der Schreibrecht auf ein Verzeichnis hat, in diesem Verzeichnis eine neue Datei an, so erhält diese Datei im Normalfall immer die Gruppenmitgliedschaft der primären Gruppe dieses Users, der sie angelegt hat. Wenn jedoch zB mehrere User an einem gemeinsamen Projekt arbeiten aber unterschiedliche primären Gruppen angehören, ist das sehr unpraktisch, da der Zugriff auf die gemeinsamen Dateien dann über "Rest der Welt" geregelt werden müssten. Wird auf ein Verzeichnis jedoch dieses SGID gesetzt, dann erhält eine neu angelegte Datei immer die Gruppenzugehörigkeit des Verzeichnisses, unabhängig von der Gruppenzugehörigkeit des Users, der diese Datei anlegt. Mit diesem Mechanismus sind also Arbeitsverzeichnisse für bestimmte Projektgruppen realisierbar. Diese Eigenschaft gilt rekursiv auch für die Unterverzeichnisse, soweit dort nichts anderes konfiguriert ist.

Sticky Bit

Das Sticky Bit hat nur noch eine Bedeutung für Verzeichnisse. (In frühen Linuxversionen gab es auch Funktionen für normale Dateien mit Sticky Bit die spezielle Behandlung solcher Dateien bewirkten) Weiter oben wurde schon ein Problem erwähnt, daß ein User, mit Schreibrecht auf ein Verzeichnis, auch Datein löschen kann, auf die er sonst keine Rechte hat. Hier setzt jetzt dieses Sticky Bit an und verhindert genau das. In einem Verzeichnis in dem dieses Bit gesetzt ist, kann nur der Besitzer dieser Datei und natürlich Root diese Datei löschen. Auch dieses Bit wirkt rekursiv auf alle Unterverzeichnisse. Das Sticky Bit kann nur von Root gesetzt werden und wird bei ls -l als t anstatt des x beim Rest der Welt angezeigt. Ein logisch unvollständig gesetztes Bit wird als T angezeigt.

In einem Verzeichnis, in dem jeder User Schreibrecht haben muß oder soll, wie etwa /tmp , sollte unbedingt dieses Bit gesetzt werden.

Octale Zuweisung der speziellen Zugriffsrechte

Um die speziellen Rechte auch numerisch darzustellen, wird vor den oben genannten "normalen" Rechten noch eine vierte Oktalziffer am Anfang angefügt, so daß sich das folgende Logik ergibt:

Octale Zuordnung der Zugriffs- und Sonderrechte

Sonderrechte			User			Gruppe			Rest
SUID	SGID	Sticky	r	w	x	r	w	x	r	w	x
4	2	1	4	2	1	4	2	1	4	2	1

Ein Recht von 4755 bedeutet demnach, das Substitute UserID Bit ist gesetzt (4), der Eigentümer hat Lese-, Schreib- und Ausführungsrechte (1+2+4=7), während sowohl Gruppenmitglieder, als auch der Rest der Welt nur Lese- und Ausführungsrecht (1+4=5) besitzen. Wenn ein User dieses Programm ausführt, erhält dieser Prozess während der Laufzeit die Rechte des Besitzers dieser Datei.

Access Control Lists unter Linux

Robi 23:23, 20. Okt 2006 (CEST)