Zugriffsrechte

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 Besitzverhältnisse 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

Oktale Zuweisung der Zugriffsrechte

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

Oktale Zuordnung der Zugriffsrechte

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

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

Für alle, die noch etwas unsicher sind und gerne mal etwas mit den Zugriffsrechten üben möchten, ein interaktives Helferlein zum spielen.

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 normalerweise auch für ausführbare Binärprogramme 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 Inode 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

Will man in ein durch einen Pfad angegebenes Verzeichnis wechseln, so muss man das Ausführungsrecht für alle Verzeichnisse innerhalb dieses Pfades besitzen. Ist das Ausführungsrecht nicht gegeben, kann in diesem Verzeichniss auch keine Zuordnung von Dateinamen zur Inode erfolgen und somit auch kein Lesen, Schreiben oder Ausführen der Dateien in diesem Verzeichniss erfolgen, egal wie die Zugriffsrechte der dortigen Dateien gesetzt ist. Ähnliches gilt für fehlendes Leserecht im Verzeichniss, ist es nicht gesetzt kommt man eventuell über das Ausführungsrecht in das Verzeichniss, kann dort aber die Dateinamen nicht auflösen. Auch ein find Befehl würde hier mit einer Fehlermeldung abgewiesen. Allerdings wenn man dort den Namen eines Verzeichnisses kennt (mit ls anzeigen geht ja nicht) kann man in dieses Verzeichniss wechseln, sofern dort die Ausführungsrechte gesetzt sind und auch auf Dateien unterhalb dieses Verzeichnisses hat man wieder vollen Zugriff entsprechend der gesetzten Zugriffsrechte der Dateien. Man kann also so ganze Dateibäume vor neugierigen Blicken verstecken, ohne den Zugang zu bekannten Dateien innerhalb dieses Dateibaumes zu verbauen. (Linuxneulingen ist aber dringend anzuraten auf solche Methoden bei Verzeichnissen zu verzichten, wenn sie nicht wirklich sicher sind, welche weiteren Nebenwirkungen zB auf ein Backup damit verbunden sind)

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 kein 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. Eine besondere Bedeutung erlangen die Zugriffsrechten von Mountpoints. Hiermit können je nach Mountoption und Filesystemtype Eigenschaften für ein ganzes Filesystem beeinflußt werden.

Symbolische Links

Symbolische Links haben immer alle Zugriffsrechte gesetzt, 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 eine weitere (führende) Octalziffer darstellt. Dabei handelt es sich um das Set UserID Bit (4), das Set GroupID Bit (2) und das Sticky Bit (1).

Set 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. Nun hat das Programm /usr/bin/passwd , deren Eigentümer root ist, das Set 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 Prozess, das Passwort auch zu wirklich zu ändern.

Das ist beim Passwort-Programm nicht problematisch, jedoch können mit diesem Zugriffsrecht richtige Sicherheitslücken entstehen, 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.

Set 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 Set 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. Dazu kann man zB. regelmäßig den folgenden Befehl abgeben. Dieser sucht das gesamte System nach solchen Dateien ab und schreibt die Namen in eine Logdatei mit Datumskennung unterhalb des Homeverzeichnisses von root. Diese kann man dann mittels diff auf Veränderungen zur letzen Logdatei prüfen. Differenzen sollte man dann auf Plausibilität überprüfen.

 find / -type f \( -perm -02000 -o -perm -04000 \) -print > ~root/SUID_SGID.log`date +"%d%m%y"`

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 solches 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 dann spezielle Behandlung solcher Dateien bewirkte, die aber in heutigen Systemen mehr hinderlich als nützlich wäre). Weiter oben wurde schon ein Problem erwähnt, daß ein User, mit Schreibrecht auf ein Verzeichnis, auch Dateien 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.

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

Oktale 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 Set 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.

Befehle rund um die Zugriffsrechte

chmod

chmod (change mode) ist der Befehl mit dem Zugriffsrechte von Dateien und Verzeichnissen direkt geändert werden können. Das Recht zum Ändern der Zugriffsrechte hat neben Root nur der Besitzer der Datei.

Die prinzipielle Anwendung ist einfach:

chmod [Optionen] Modus Datei(en)

Als Modus kann entweder ein numerischer (octaler), oder ein symbolischer Modus angegeben werden. Der numerische Modus entspricht dem, was im letzten Abschnitt beschrieben wurde, er kann sowohl 3 als auch 4 stellig angegeben werden. (häufig wird er auch 5 Stellig angegeben mit einer führenden 0 als Kennzeichen für die Shell, daß es sich um einen Octalzahl handelt).

Ein typisches Beispiel für den Aufruf

 chmod 644 foo.txt

würde der Datei foo.txt ein Zugriffsrecht von rw-r--r-- geben. Mit numerischem Modus wird grundsätzlich immer ein absoluter Wert gesetzt, unabhängig, welche Rechte vorher auf die Datei gesetzt waren.

Der symbolische Modus ist mehrteilig und besteht aus einer Angabe

• für wen die Rechte geändert werden sollen Form von Buchstaben
• einem Zuweisungszeichen mit dem bestimmt wird, wie sich die neuen Rechte logisch aus den ursprünglichen und den innerhalb des Befehl verwendeten zusammensetzen sollen
• und der Rechte die gesetzt oder geändert werden sollen auch in Buchstaben.

Die grundsätzliche Form ist:

[ugoa]+|-|=[rwxstugo],...

Das führende Zeichen steht für die zu verändernde Kategorie,

• u steht für User (Eigentümer)
• g für group (Gruppenmitglied)
• o für other (Andere)
• a steht für all (Alle) Wird dieses führende Zeichen weggelassen, dann wird a angenommen.

Es können auch mehrere führende Zeichen kombiniert werden. zB. ug würde interpretiert als Änderen der Rechte von User und Gruppe.

Vorsicht: häufiger Fehler die interpretation von o mit dem Begriff Owner (Eigentümer). Das kann fatale Folgen haben, weil man dann die Rechte, die man eigentlich dem Eigentümer geben will, dem Rest der Welt verleiht!

Das folgende Zuweisungszeichen +, - oder = beschreibt wie die Rechte den schon bestehenden Rechten

• hinzugefügt (+) werden soll
• davon abgezogen (-) werden soll
• oder absolut (=) also genau so gesetzt werden soll

Dem Zuweisungszeichen folgt die Angabe der zu setzenden (oder addierenden oder subtrahierenden) Rechte in der Form einer Zeichenkette, die aus den Buchstaben r,w,x,X,s,t,u,g,o bestehen kann.

• r Read (lesen)
• w Write (schreiben)
• x Execute (ausführen)
• X Execute (ausführen) das Recht wird nur für Verzeichnisse gesetzt, für normale Dateien nicht
• s SUID und SGID je nach Stellung bei User oder Gruppe
• t Sticky Bit bei Zuweisung zu Rest der Welt

Folgen dieser Angabe noch ein u, g oder o, so bedeutet dies ein Ausschlußkriterium in Verbindung mit dem a am Anfang. Das nachgestellte u, g oder a schützt so die Rechte der User, Gruppenmitglieder bzw. Anderen vor Veränderung. Dieses ist jedoch eine sehr unübersichtliche Schreibweise, und sollte nur in Ausnahmefällen verwendet werden.

Diese Angaben können auch mehrmals, jeweils mit Komma getrennt, in einem Befehl angewandt werden, wichtig jedoch der gesamte symbolische String darf keine Leerzeichen enthalten.

Ein typischer Beispielaufruf:

 chmod u=rwx,g=rx,o-rwx foo

setzt für User rwx und für die Gruppe r-x und nimmt allen Anderen eventuell gesetzte Rechte. Als Ergebniss resultiert in Jedem Fall das Recht rwxr-x---. Oftmals einfacher ist hier die Benutzung der Octalwerte (hier 750)

Praktisch an der symbolischen Angabe der Modi ist die Fähigkeit, bestimmte Rechte auf die bestehenden Rechte aufzuaddieren bzw. sie von den bestehenden Rechten abzuziehen. Ein einfaches +x bedeutet z.B., daß allen drei Kategorien User, Group und Other ein Ausführungsrecht zu den schon vorhandenen Rechten gegeben wird.

Eine wichtige Option von chmod ist -R oder --recursive, damit kann chmod die Rechte eines ganzen Verzeichnisbaumes mit nur einem Befehl ändern.

umask

Mit umask werden die Zugriffsberechtigungen für neue Dateien bestimmt. Damit wird abgefragt bzw. festgelegt, welche Zugriffsberechtigungen beim Anlegen einer Datei verwendet werden. Die Anwendung ist aber auf den ersten Blick verwirrend und etwas merkwürdig.

• Der Befehl umask ist ein Shellbuildin, er ist also fest in die Shell eingebaut. Obwohl die prinzipielle Funktion in allen Shell gleich ist, sprechen wir hier von umask der bash.

Zum Setzen der Zugriffsberechtigung erwartet umask eine Maske als Parameter. Das Wort Maske bedeutet hier jedoch, es werden nicht die Werte des Zugriffsmodus angegeben, die gesetzt werden sollen, sondern umgekehrt, die Werte, die nicht gesetzt (maskiert) werden sollen. Die Maske ist der invertierte Wert der gewünschten Zugriffsrechte.

Die einfachste Möglichkeit die Maske zu ermitteln, besteht darin, die gewünschten oktalen Werte jeweils von 7 abzuziehen.

• Beispiel : es soll das Zugriffrecht rw-r----- für neue Dateien gesetzt werden.

Diffenz zu 777

	7	7	7
Zugriffsrecht	6	4	0
Maske	1	3	7

Die folgende Tabelle soll die Zusammenhänge zwischen Zugriffsrecht und Maske weiter verdeutlichen

Berechnung umask am Beispiel

Zugriffsrechte
	User			Gruppe			Rest
symbolisch	r	w	-	r	-	-	-	-	-
octal einzeln	4	2	0	4	0	0	0	0	0
octal	6			4			0
Maske
	User			Gruppe			Rest
octal	1			3			7
octal einzeln	0	0	1	0	2	1	4	2	1
symbolisch	-	-	x	-	w	x	r	w	x

Hier ist noch kleinen Haken, die Verzeichnisse. Würden wir diese mit dem Modus 640 erstellen, wäre für uns selbst das Durchsuchungs-/Betretungs-Recht (x) nicht gesetzt. Linux hat aus diesem Grund dafür den Mechanismus entwickelt, daß selbst wenn im umask-Kommando das x-Recht gesetzt ist, beim Erzeugen von normalen Dateien dieses Recht nicht gesetzt wird, beim Erzeugen von Verzeichnissen hingegen schon. ( es gibt einige wenige Ausnahmen, zB Kompiler, die ja auführbare binäre Dateien erstellen, diese werden für ausführbare Dateien auch das (x) entsprechend der umask Maske richtig setzen )

Ein vernünftiges umask-Kommando setzt also zumindestens für den Eigentümer auch das (x)-Recht.
Damit wäre ein typischer Wert für umask z.B. 022 (rwxr-xr-x) oder 027 (rwxr-x---).

Neben der octalen Form gibt es aber auch die symbolische Form, die die Rechte direkt bezeichnet, also nicht invertiert.
Sie wird in der Form u=...,g=...,o=... eingegeben, wobei für ... immer die entsprechenden Rechte eingesetzt werden. Also würde der Befehl

umask u=rwx,g=rx,o=

die gleiche Wirkung haben wie

umask 027

Typischerweise steht eine umask-Anweisung in einer der Shell-Startdateien wie z.B. /etc/profiles oder ~/.profile. Jeder User kann somit seine Voreinstellung also auch selbst einstellen. Eine der wenigen Möglichkeiten, mit denen der User dem Systemverwalter ins Handwerk pfuschen kann, wenn dieser versucht, sein System sicher zu machen. Allerdings bezieht sich diese Einstellung ja dann nur auf die neu anzulegenden Dateien des jeweiligen Users.

Zum Abrufen der aktuelle gesetzten Maske für umask einfach das Komando ohne Maske oder mit der Option -S für den symbolischen Modus aufrufen.

LINUX:/ # umask
0022
LINUX:/ # umask -S
u=rwx,g=rx,o=rx

mount

Der mount Befehl steht mit den Zugriffsrechten in besonderer Beziehung. Einerseits müssen über das Mounten der Filesysteme auch nicht LINUX-kompatible Zugriffssteuerungen von verschiedenen Filesystemen für Linux kompatibel gemacht werden, andererseits muss über das Mounten verhindert werden, daß zB. Programme und Zugriffsregelungen von den gemounteten Filesystemen ein Sicherheitsrisiko für das System darstellen könnten. Neben den Zugriffsrechten des Mountpointes , spielen hier einige Optionen von mount eine besondere Bedeutung.

• einige wichtige Optionen von mount in Verbindung mit Zugriffsrechten: selbstverständlich gibt es zu einigen Optionen auch das genaue Gegenteil, die hier allerdings nicht extra aufgeführt werden:

ro 

(read only) egal was für Zugriffsrechte auf dem gemounteten Filesystem gesetzt sind, es kann in diesem Filesystem nur gelesen werden

nodev 

(no devices) eventuell auf dem Filesystem befindliche Geräteknoten werden vom System nicht unterstützt

nosuid 

(no SUID) eventuell auf dem Filesystem befindliche SUID oder SGID werden ignoriert

noexec 

(no execute) eventuell auf dem Filesystem befindliche ausführbare Binärdateien können nicht ausgeführt werden.

• Für einige Filesystem deren Zugriffsteuerung nicht Linuxkompatibel ist gibt es noch spezielle Optionen:

uid= 

setzt die UserID als Eigentümer der Dateien im Filesystem

gid= 

setzt die GruppenID als Gruppe der Dateien im Filesystem

umask= 

setzt die universal mask mit der die für den jeweiligen Mountpoint gesamten Dateirechte und Verzeichnisrechte vererbbar logisch Nicht-Und verknüft werden

dmask= 

setzt die directorymask mit der die für den jeweiligen Mountpoint gesamten Dateirechte vererbbar logisch Nicht-Und verknüft werden

fmask= 

setzt die filemask mit der die für den jeweiligen Mountpoint gesamten Verzeichnisrechte vererbbar logisch Nicht-Und verknüpft werden

• Dabei werden die Masken analog zum umask-Befehl auf den jeweiligen Mountpoint und alle darunterliegenden Verzeichnise bzw. Dateien angewandt(=Vererbbarkeit von Rechten) in der Form, daß die mit chmod setzbaren Rechte einfach mit der jeweiligen Maske logisch Nicht-Und verknüpft werden. Ein Beispiel dafür ist eine Datei mit den oktalen Ausgangsberechtigungen 0700 die kombiniert mit umask=0022 nach einem chmod 1777 <Dateiname> die effektiven oktalen Dateirechte 1755 erhält.

Zugriffsrechte beim kopieren und verschieben

Beim Kopieren mit 'cp wird immer eine neue Datei erstellt, die alte Datei bleibt sowohl im Besitz wie auch mit den Orginalrechten erhalten. Die neu erzeugte Datei erhält die UserID und die GruppenID des kopierenden Users. Die normalen Zugriffsrechte werden so übernommen wie sie in den zu kopierenden Dateien gesetzt waren. Unterschiede gibt es bei den speziellen Zugriffsrechten. Während in einigen Fällen ein ( S ) mit übernommen wird, wird beim kopieren eines normalen Users ( s ) nicht übernommen, aber ( t ) als auch ( T ) dagegen schon. Bei einer Kopie als root werden auch die erweiterten Rechte komplett übernommen. hier ist also als root besondere Vorsicht geboten wenn Binärdateien eines Users von root mit cp kopiert werden

Beim Verschieben mit mv müssen wir prinzipell unterscheiden, wohin verschoben wird. Bleibt die Datei im selben Filesystem, dann wird sie nur umbenannt, dass bedeutet die Inode bleibt so erhalten wie sie war, sie wird nur in den Verzeichnissdateien neu zu den Dateinamen verlinkt. Damit bleiben natürlich in diesem Falle sowohl der User die Gruppe und die Zugriffsrechte, alles so wie sie waren.

Etwas anders sieht es aus, wenn wir mittels mv in ein anderes Filessystem verschieben. Hier wird die Datei in dem neuem Verzeichniss neu angelegt und anschließen im altem Dateisystem gelöscht. Dabei erhält die Datei die Besitzverhältnisse der Orginaldatei nur, wenn das von root ausgeführt wird, bei einem anderem User werden die Besitzverhältnisse des Verschiebenden Users gesetzt. Die Zugriffsrechte einschließlich der speziellen Zugriffsrechte werden jedoch in jedem Falle genau so gesetzt, wie in den Orginaldateien.

Daran ändert sich auch nichts wenn der verschiebende User nicht das Recht besitzt, die orginal Dateien zu löschen. In diesem Fall werden die Dateien kopiert, und die Rechte und Besitzverhältnisse gesetzt wie beim Verschieben, allerdings können die Orginaldateien nicht gelöscht werden, was auch durch Fehlermeldungen quitiert wird. Trotz dieser Fehlermeldungen wurden aber die Dateien quasi kopiert, sind jetzt also doppelt vorhanden.

TIP: Es ist also durchaus keine schlechte Angewohnheit, wenn man sich angewöhnt, nach dem kopieren oder verschieben von Dateien die Eigentums und Zugriffsrechte noch einmal genauer anzuschauen.

Zugriffsrechte bei Eigentumswechsel

Weniger kritisch ist der Eigentumswechsel von Dateien mittels chown und chgrp. Abgesehen davon, dass dieses nur von root selbst gemacht weden kann, bleiben die Zugriffsrechte und speziellen Zugriffsrechte erhalten, und nur die UserID und GruppenID wird geändert.

Erweiterte Dateiattribute im ext2-Dateisystem

Erweiterte Dateiattribute im EXT2-Dateisystem Dateien auf ext2/ext3-Dateisystemen besitzen neben den normalem Zugriffsattributen noch weitere. Diese Attribute werden in den zusätzlichem Flag (Wahlschalter der ext2-Inode) gespeichert. Die gesetzten Attribute können mit dem Befehl lsattr angezeigt und mit chattr verändert (gesetzt) werden.

Der Aufruf zum Verändern der Attribute erfolgt mit chattr +-=[ASacDdIijsTtu] DATEI

• der Operator ( + ) bedeutet diese Attribut wird zusätzlich gesetzt
• der Operator ( - ) bedeutet diese Attribut wird zurückgesetzt
• der Operator ( = ) bedeutet die Attribute werden genau so gesetzt wie im Befehl angegeben

Die Attribute im Überblick:

Zusätzliche Dateiattribute im ext2-Dateisystem

Attribut	Erkärung
A	Die atime von Dateien oder Verzeichnissen mit diesem Flag wird bei Zugriff nicht verändert. analog Mount-Option "noatime" bei vielen Dateisystemen .
S	Dateien werden synchron geschrieben, alle Schreiboperation werden unter Umgehung des Write-Back-Caches direkt auf die Partition ausgeführt. (sync)
a	Dateien mit diesem Flag können am Ende beschrieben werden, nicht jedoch beliebig überschrieben oder geändert werden. Das ist z.B. für Logfiles geeignet. Achtung : nicht in Verbindung mit Netzwerkdateisystemen verwenden
c	Datei wird automatisch komprimiert auf Platte geschrieben. Der Userzugriff über das Filesystem erfolgt aber unkompimiert.
D	Auf Verzeichnisse mit diesem Flag wird synchron geschrieben. Alle Schreibzugriffe werden direkt auf die Platte ausgeführt und nicht gepuffert. (dirsync)
d	Dateien mit diesem Attribut werden von dump nicht gesichert.
I	Statusflag mit Sonderfunktion, kann nicht mit chattr gesetzt oder gelöscht werden
i	Immutable-Flag kann nur von root verändert werden. Ist es gesetzt, kann die Dateis nicht verändert werden, auch nicht von root. Root könnte natürlich das Flag auch wieder entfernen.
j	Daten eines solchen Files werden durch das ext3-Journal vor Korruption geschützt, (nur wenn journaling ausgeschaltet) Darf nur von root verändert werden.
s	Die Daten der Files werden beim Löschen vernichtet und nicht nur als "frei" markiert. Geeignet für sensible Daten (z.B. Passwörtfiles)
T	top of directory hierarchy (gilt für Verzeichnisse, genaue Funktion unklar)
t	Option verhindert, daß sich eine Datei (wenn die Dateigrösse kein natürliches Vielfaches der Blockgröße ist) u.U. den letzten Block mit anderen Dateien teilen muss. Daß ist nur bei Dateien nötig, auf die unter Umgehung des Filesystemtreibers zugegriffen werden müßte (z.B. für /vmlinuz , wenn es durch lilo beim Bootvorgang von der Platte gelesen wird)
u	Die "undelete"able-Option sorgt dafür, dass eine Datei beim Löschen nicht wirklich gelöscht wird. Root kann die Datei bei Bedarf problemlos wiederherstellen.
Z	experimental für Kompression genutzt, kann nicht mit chattr verändert werden
X	experimental für Kompression genutzt, kann nicht mit chattr verändert werden

Man sollte beachten, dass für einige experimentelle Funktionen einiger Attribute bestimmte Kernelversionen oder zusätzliche Patches im Kernel voraussetzten.

LINUX:/data1/test # touch test1 test2 test3 test4
LINUX:/data1/test # ls -l
insgesamt 8
drwxr-xr-x   2 root root 4096 2006-10-24 17:44 .
drwxrwxrwx  26 root root 4096 2006-10-10 21:59 ..
-rw-r--r--   1 root root    0 2006-10-24 17:44 test1
-rw-r--r--   1 root root    0 2006-10-24 17:44 test2
-rw-r--r--   1 root root    0 2006-10-24 17:44 test3
-rw-r--r--   1 root root    0 2006-10-24 17:44 test4
LINUX:/data1/test # lsattr *
------------- test1
------------- test2
------------- test3
------------- test4
LINUX:/data1/test # chattr +u test3
LINUX:/data1/test # chattr +i test2
LINUX:/data1/test # chattr +a test1
LINUX:/data1/test # chattr +s test4
LINUX:/data1/test # lsattr *
-----a------- test1
----i-------- test2
-u----------- test3
s------------ test4

Access Control Lists unter Linux

Access Control Lists (Zugriffskontrolllisten), werden bei Betriebssystemen zum Kontrollieren der Zugriffsberechtigungen auf diverse Ressourcen wie Dateien und Programme, verwendet. Unter Linux unterstützen eine Reihe Dateisysteme ACLs vollständig Posix ACLs.

Weiterführende Links zu ACL

• POSIX Access Control Lists on Linux
• ACL Manpages
• weitere ACS Links zB dewiki.de

Probleme mit Zugriffsrechten in Netzwerkfilesystemen

Der Mythos des x-Bits

Was mit den normalen Unix/Linuxrechten funktioniert, das wird im Netzwerk ein Problem. ZB. die exakte Trennung zwischen den Rechten

• Ausführen eines Programmes und
• Lesen in dieser Datei

können in Netzwerkdateisystemen so nicht durchgesetz werden, auch wenn es durch entsprechende Impementierung auf Clientseite vielleicht so scheint.

Beispiel: Ein geheimes Programm auf einem Filesserver soll jeder ausführen dürfen, aber niemand soll es Lesen können. Für den Fileserver stellt das einen schlicht unlösbaren Widerspruch dar. Für ihn macht es ja gar keinen Unterschied, ob eine Datei von einem Client abgeholt wird, um sie zu lesen oder um sie auszuführen. Und selbst dann, wenn der Client eine Versicherung der Art: "Ich will diese Datei nur ausführen, auf keine Fall lesen" mitschickt, der Server kann die Richtigkeit dieser Angabe nur annehmen, aber nicht nachprüfen.

Problem der Authentifizierung am Client

Der Server des Netzwerkdateisystemes muß aber irgendwie erkennen, wer gerade versucht eine Datei von ihm abzurufen. Ansonsten, ist eine Rechteverwaltung des Dateisystems ganz sinnlos. Dazu muss sich der User in irgend einer Art ausweisen, also authentifizieren. Bei den klassischen lokalen Dateisystemen ist das einfach, der Benutzer kann sich mit der UID des jeweiligen Prozesses eindeutig zu erkennen geben. Unter dieser UID kann er nur arbeiten, wenn er sich mit seinem Passwort am Rechner angemeldet hat. Ausnahme hier vielleicht, root darf natürlich alles, der kann sich ja in jeden Benutzer verwandeln.

Im Netzwerk ist eine eindeutige Authentifizierung etwas schwieriger und es wurden schon ganze Bücher damit gefüllt. Die einfachste, jedoch unsichere Methode ist die Authentifizierung am Client, wie bei NFS bis Version 3 default voreingestellt. Bei jeder Anfrage an den Server wird an den Server die UID des Benutzers auf dem Client mitgeschickt. Der Server prüft dann diese UID auf ihre Zugriffsrecht zum Beispiel für den Lesezugriff auf diese Datei und gewährt oder verweigert den Zugriff.

Der Server muss dabei jedoch im gutem Glauben davon ausgehen, dass auf dem Client überhaupt erstmal Passwörter existieren und daß sich dort nicht jeder einfach mal so als root anmelden kann, um dann die ID irgend eines Users für Netzwerkzugriffe zu erlangen. Die Daten in einem solchen Netzwerk sind somit nur so sicher, wie die Clients absichert werden können. Diese Form der Netzwerksicherheit ist zwar sehr weit verbreitet, sicherheitstechnisch aber schon vollkommen überholt.

Authentifizierung am Server

Wenn man die Clients nicht absichern kann, dann muss man eben eine sichere Authentifizierung am Server gewähleisten. Dazu gibt es mehrere Lösungsansätze, mit unterschiedlichen Stärken und Nachteilen:

1. Die Verbindung zum Server wird in Form ein Sitzung vor dem ersten Zugriff aufgebaut. (siehe zB.: Zugriffrechte unter Samba)
2. mit jeder Anfrage an den Server wird ein geheimes Datenpaket mitgesendet.
3. Ticketbasierte Authentifikation am Server. Dabei wird vor dem ersten Zugriff z.B. das Passwort benutzt, um von einem speziellen Sicherheitsserver ein Ticket-Datenpaket (Token) zu bekommen. Diese wird bei jedem Zugriff vorgelegt. Dieses Ticket ist nur eine begrenzte Zeit (wenige Stunden) gültig. Nach Ablauf der Zeit, akzeptiert der Server das Ticket nicht mehr, und man muss sich vom Sicherheitsserver ein neues Ticket holen.

Links zu Network Filesysteme

• Network_File_System
• OpenAFS.org
• NFS