Linupedia.org - Benutzerbeiträge [de]

Zugriffsrechte

2010-01-03T19:50:52Z

Ceekay: /* Sticky Bit */

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 von Dateien|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
<pre>
-rw-rw-r-- 1 otto wiki 1916 Jul 29 2006 ftp.wiki
</pre>

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:

{|style="height:50px" border="1"
|+ '''Oktale Zuordnung der Zugriffsrechte'''
! style="width:150px" colspan="3" align="center"| User
! style="width:150px" colspan="3" align="center"| Gruppe
! style="width:150px" colspan="3" align="center"| Rest
|-align="center"
| r || w || x || r || w || x || r || w || x
|-align="center"
| 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, [http://de.selfhtml.org/helferlein/chmod.htm 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 [[Library]]s 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 [[Mountpoint]]s. 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:

{|style="height:50px; background:silver" border="1"
|+ '''Oktale Zuordnung der Zugriffs- und Sonderrechte'''
! style="width:150px; background:yellow" colspan="3" align="center"| Sonderrechte
! style="width:150px" colspan="3" align="center"| User
! style="width:150px" colspan="3" align="center"| Gruppe
! style="width:150px" colspan="3" align="center"| Rest
|-align="center"
| style="background:yellow" |SUID
| style="background:yellow" |SGID
| style="background:yellow" |Sticky || r || w || x || r || w || x || r || w || x
|-align="center"
| style="background:yellow" |4
| style="background:yellow" |2
| style="background:yellow" |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 ===

[http://www.openbsd.org/cgi-bin/man.cgi?query=chmod&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html chmod] ('''ch'''ange '''mod'''e) 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 [[#Octale Zuweisung der speziellen Zugriffsrechte|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 [http://www.openbsd.org/cgi-bin/man.cgi?query=umask&format=html 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.
{|style="height:50px; width:33% " border="1"
|+ '''Diffenz zu 777'''
|- style="background:silver" align="center"
|
| 7
| 7
| 7
|- align="center"
| Zugriffsrecht
| 6
| 4
| 0
|- style="background:yellow" align="center"
| Maske
| 1
| 3
| 7
|}

Die folgende Tabelle soll die Zusammenhänge zwischen Zugriffsrecht und Maske weiter verdeutlichen
{|style="height:50px" border="1"
|+ '''Berechnung umask am Beispiel'''
|- style="background:silver" align="center"
| colspan="10" | Zugriffsrechte
|-
|
! style="width:150px" colspan="3" align="center"| User
! style="width:150px" colspan="3" align="center"| Gruppe
! style="width:150px" colspan="3" align="center"| Rest
|-align="center"
! symbolisch
| r || w || - || r || - || - || - || - || -
|-align="center"
! octal einzeln
| 4 || 2 || 0 || 4 || 0 || 0 || 0 || 0 || 0
|- align="center"
! octal
| colspan="3" | 6
| colspan="3" | 4
| colspan="3" | 0
|- style="background:silver" align="center"
| colspan="10" | Maske
|-
|
! style="width:150px" colspan="3" align="center"| User
! style="width:150px" colspan="3" align="center"| Gruppe
! style="width:150px" colspan="3" align="center"| Rest
|- align="center"
! octal
| colspan="3" | 1
| colspan="3" | 3
| colspan="3" | 7
|-align="center"
! octal einzeln
| 0 || 0 || 1 || 0 || 2 || 1 || 4 || 2 || 1
|-align="center"
! 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 [http://www.openbsd.org/cgi-bin/man.cgi?query=mount&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html 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 [[Mountpoint]]es , 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 [[Inode|ext2-Inode]]) gespeichert. Die gesetzten Attribute können mit dem Befehl '''[http://www.linux-praxis.de/lpic1/manpages/lsattr.html lsattr]''' angezeigt und mit '''[http://www.linux-praxis.de/lpic1/manpages/chattr.html 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:

{| Border="1"
|+ '''Zusätzliche Dateiattribute im ext2-Dateisystem'''
|-
!Attribut
! Erkärung
|-
|align="center" | A || Die '''atime''' von Dateien oder Verzeichnissen mit diesem Flag wird bei Zugriff nicht verändert. ''analog Mount-Option "noatime" bei vielen Dateisystemen .
|-
|align="center" |S || Dateien werden synchron geschrieben, alle Schreiboperation werden unter Umgehung des Write-Back-Caches direkt auf die Partition ausgeführt. (sync)
|-
|align="center" |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 ''
|-
|align="center" |c || Datei wird automatisch komprimiert auf Platte geschrieben. Der Userzugriff über das Filesystem erfolgt aber unkompimiert.
|-
|align="center" |D || Auf Verzeichnisse mit diesem Flag wird synchron geschrieben. Alle Schreibzugriffe werden direkt auf die Platte ausgeführt und nicht gepuffert. (dirsync)
|-
|align="center" |d || Dateien mit diesem Attribut werden von '''dump''' nicht gesichert.
|-
|align="center" |I || Statusflag mit Sonderfunktion, kann nicht mit chattr gesetzt oder gelöscht werden
|-
|align="center" |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.
|-
|align="center" |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.
|-
|align="center" |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)
|-
|align="center" |T || top of directory hierarchy ''(gilt für Verzeichnisse, genaue Funktion unklar)''
|-
|align="center" |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)''
|-
|align="center" |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.
|-
|align="center" | Z || experimental für Kompression genutzt, kann nicht mit chattr verändert werden
|-
|align="center" | 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.
<pre>
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
</pre>

== [http://de.wikipedia.org/wiki/Access_Control_List 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 folgende Dateisysteme ext2, ext3, [http://de.wikipedia.org/wiki/Journaled_File_System JFS], [http://de.wikipedia.org/wiki/XFS_%28Dateisystem%29 XFS] und [http://de.wikipedia.org/wiki/ReiserFS ReiserFS] ACLs vollständig Posix ACLs

=== Weiterführende Links zu ACL ===

* [http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux]
* [http://acl.bestbits.at/man/man.shtml ACL Manpages]
* [http://de.opensuse.org/SDB:POSIX_Access_Control_List_(ACL)_-_Unterst%C3%BCtzung SDB:POSIX Access Control List (ACL) - Unterstützung]

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

# Die Verbindung zum Server wird in Form ein Sitzung vor dem ersten Zugriff aufgebaut. ''(siehe zB.: [[Zugriffrechte unter Samba]])''
# mit jeder Anfrage an den Server wird ein geheimes Datenpaket mitgesendet.
# 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 ===

* [http://de.wikipedia.org/wiki/Network_File_System Network_File_System]
* [http://www.openafs.org/ OpenAFS.org]
* [http://fbo.no-ip.org/cgi-bin/twiki/view/Instantafs/WebHome InstantAFS]
* [http://www.protocols.com/pbook/nfs.htm NFS Protocol Family]

[[Benutzer:Robi|Robi]] 23:23, 20. Okt 2006 (CEST)
[[Category:Security]]
[[Category:Konsole]]
[[Category:Linux-intern]]

Zugriffsrechte

2010-01-03T19:43:08Z

Ceekay: /* Set UserID Bit (SUID) */

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 von Dateien|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
<pre>
-rw-rw-r-- 1 otto wiki 1916 Jul 29 2006 ftp.wiki
</pre>

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:

{|style="height:50px" border="1"
|+ '''Oktale Zuordnung der Zugriffsrechte'''
! style="width:150px" colspan="3" align="center"| User
! style="width:150px" colspan="3" align="center"| Gruppe
! style="width:150px" colspan="3" align="center"| Rest
|-align="center"
| r || w || x || r || w || x || r || w || x
|-align="center"
| 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, [http://de.selfhtml.org/helferlein/chmod.htm 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 [[Library]]s 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 [[Mountpoint]]s. 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 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.

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

{|style="height:50px; background:silver" border="1"
|+ '''Oktale Zuordnung der Zugriffs- und Sonderrechte'''
! style="width:150px; background:yellow" colspan="3" align="center"| Sonderrechte
! style="width:150px" colspan="3" align="center"| User
! style="width:150px" colspan="3" align="center"| Gruppe
! style="width:150px" colspan="3" align="center"| Rest
|-align="center"
| style="background:yellow" |SUID
| style="background:yellow" |SGID
| style="background:yellow" |Sticky || r || w || x || r || w || x || r || w || x
|-align="center"
| style="background:yellow" |4
| style="background:yellow" |2
| style="background:yellow" |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 ===

[http://www.openbsd.org/cgi-bin/man.cgi?query=chmod&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html chmod] ('''ch'''ange '''mod'''e) 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 [[#Octale Zuweisung der speziellen Zugriffsrechte|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 [http://www.openbsd.org/cgi-bin/man.cgi?query=umask&format=html 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.
{|style="height:50px; width:33% " border="1"
|+ '''Diffenz zu 777'''
|- style="background:silver" align="center"
|
| 7
| 7
| 7
|- align="center"
| Zugriffsrecht
| 6
| 4
| 0
|- style="background:yellow" align="center"
| Maske
| 1
| 3
| 7
|}

Die folgende Tabelle soll die Zusammenhänge zwischen Zugriffsrecht und Maske weiter verdeutlichen
{|style="height:50px" border="1"
|+ '''Berechnung umask am Beispiel'''
|- style="background:silver" align="center"
| colspan="10" | Zugriffsrechte
|-
|
! style="width:150px" colspan="3" align="center"| User
! style="width:150px" colspan="3" align="center"| Gruppe
! style="width:150px" colspan="3" align="center"| Rest
|-align="center"
! symbolisch
| r || w || - || r || - || - || - || - || -
|-align="center"
! octal einzeln
| 4 || 2 || 0 || 4 || 0 || 0 || 0 || 0 || 0
|- align="center"
! octal
| colspan="3" | 6
| colspan="3" | 4
| colspan="3" | 0
|- style="background:silver" align="center"
| colspan="10" | Maske
|-
|
! style="width:150px" colspan="3" align="center"| User
! style="width:150px" colspan="3" align="center"| Gruppe
! style="width:150px" colspan="3" align="center"| Rest
|- align="center"
! octal
| colspan="3" | 1
| colspan="3" | 3
| colspan="3" | 7
|-align="center"
! octal einzeln
| 0 || 0 || 1 || 0 || 2 || 1 || 4 || 2 || 1
|-align="center"
! 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 [http://www.openbsd.org/cgi-bin/man.cgi?query=mount&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html 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 [[Mountpoint]]es , 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 [[Inode|ext2-Inode]]) gespeichert. Die gesetzten Attribute können mit dem Befehl '''[http://www.linux-praxis.de/lpic1/manpages/lsattr.html lsattr]''' angezeigt und mit '''[http://www.linux-praxis.de/lpic1/manpages/chattr.html 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:

{| Border="1"
|+ '''Zusätzliche Dateiattribute im ext2-Dateisystem'''
|-
!Attribut
! Erkärung
|-
|align="center" | A || Die '''atime''' von Dateien oder Verzeichnissen mit diesem Flag wird bei Zugriff nicht verändert. ''analog Mount-Option "noatime" bei vielen Dateisystemen .
|-
|align="center" |S || Dateien werden synchron geschrieben, alle Schreiboperation werden unter Umgehung des Write-Back-Caches direkt auf die Partition ausgeführt. (sync)
|-
|align="center" |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 ''
|-
|align="center" |c || Datei wird automatisch komprimiert auf Platte geschrieben. Der Userzugriff über das Filesystem erfolgt aber unkompimiert.
|-
|align="center" |D || Auf Verzeichnisse mit diesem Flag wird synchron geschrieben. Alle Schreibzugriffe werden direkt auf die Platte ausgeführt und nicht gepuffert. (dirsync)
|-
|align="center" |d || Dateien mit diesem Attribut werden von '''dump''' nicht gesichert.
|-
|align="center" |I || Statusflag mit Sonderfunktion, kann nicht mit chattr gesetzt oder gelöscht werden
|-
|align="center" |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.
|-
|align="center" |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.
|-
|align="center" |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)
|-
|align="center" |T || top of directory hierarchy ''(gilt für Verzeichnisse, genaue Funktion unklar)''
|-
|align="center" |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)''
|-
|align="center" |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.
|-
|align="center" | Z || experimental für Kompression genutzt, kann nicht mit chattr verändert werden
|-
|align="center" | 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.
<pre>
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
</pre>

== [http://de.wikipedia.org/wiki/Access_Control_List 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 folgende Dateisysteme ext2, ext3, [http://de.wikipedia.org/wiki/Journaled_File_System JFS], [http://de.wikipedia.org/wiki/XFS_%28Dateisystem%29 XFS] und [http://de.wikipedia.org/wiki/ReiserFS ReiserFS] ACLs vollständig Posix ACLs

=== Weiterführende Links zu ACL ===

* [http://www.suse.de/~agruen/acl/linux-acls/online/ POSIX Access Control Lists on Linux]
* [http://acl.bestbits.at/man/man.shtml ACL Manpages]
* [http://de.opensuse.org/SDB:POSIX_Access_Control_List_(ACL)_-_Unterst%C3%BCtzung SDB:POSIX Access Control List (ACL) - Unterstützung]

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

# Die Verbindung zum Server wird in Form ein Sitzung vor dem ersten Zugriff aufgebaut. ''(siehe zB.: [[Zugriffrechte unter Samba]])''
# mit jeder Anfrage an den Server wird ein geheimes Datenpaket mitgesendet.
# 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 ===

* [http://de.wikipedia.org/wiki/Network_File_System Network_File_System]
* [http://www.openafs.org/ OpenAFS.org]
* [http://fbo.no-ip.org/cgi-bin/twiki/view/Instantafs/WebHome InstantAFS]
* [http://www.protocols.com/pbook/nfs.htm NFS Protocol Family]

[[Benutzer:Robi|Robi]] 23:23, 20. Okt 2006 (CEST)
[[Category:Security]]
[[Category:Konsole]]
[[Category:Linux-intern]]

RAID allgemein

2010-01-03T18:45:34Z

Ceekay: /* Hardwareraid */

Mit gewisser Regelmäßigkeit erscheint in unserem Forum die Thematik RAID. Dabei zeigt sich, dass hier neben spezieller Hilfestellung durchaus auch noch einiges an allgemeinem Informationsbedarf besteht. Aus diesem Grunde soll hier eine allgemeinverständliche komprimierte Zusammenfassung über den Mythos RAID entstehen.

== RAID was ist das überhaupt ==

=== Der Begriff RAID ===

RAID '''redundant array of inexpensive disks''' (übersetzt: Redundanter Verbund kostengünstiger Festplatten) taucht in den späten 80er Jahren erstmal auf. Die Idee dahinter, man benötigte eine Möglichkeit mit preiswerten gebräuchlichen Festplatten große und extrem teure Speichermedien zu simulieren bzw. zu ersetzen. Das dabei durch die höhere Anzahl der Festplatten entstehende höhere Ausfallrisiko sollte durch die [http://de.wikipedia.org/wiki/Redundanz_(Information) Redundanz], also das Vorkommen mehrfach gespeicherter Daten ausgeglichen werden. Doch die Entwicklung ging weiter, die verfügbaren Plattenkapazitäten haben sich fast 2 jährig verdoppelt, die Preise halbiert. Aber es gab neue Probleme für die das RAID optimale Voraussetzungen mitbrachte und die die Entwicklung von RAID voran getrieben haben. Man benötigte schnellere Zugriffszeiten, höhere Datensicherheit und größere Verfügbarkeit der Systeme. Heute spielt der Preis nur noch eine untergeordnete Rolle und man übersetzt RAID als '''redundant array of independent disks''' (übersetzt: Redundante Anordnung unabhängiger Festplatten)

=== Das Prinzip ===

Anstatt die Daten der Reihe nach auf eine einzige Platte zu schreiben, werden die Daten parallel und gleichzeitig auf mehrere Platten geschrieben. Die einfachste Methode, man teilt die Daten jeweils in kleine gleichgroße Blöcke auf, und schreibt die einzelnen Blöcke jeweils gleichzeitig auf eine bestimmte Anzahl von gleichgroßen Platten. Bei angenommenen 4 Platten wird dann nur jeder 4. Block auf eine bestimmte Platte geschrieben und die Gesamtkapazität ist 4 x die Einzelplattengröße. Gelesen wird dann genauso von allen Platten gleichzeitig. Und schon haben wir einen RAIDLEVEL definiert, '''RAID 0''' auch Striping genannt, weil die Daten wie einzelnen Streifen auf die Platten verteilt werden 

RAID 0 hat nun aber keine Redundanz, das heißt wenn auch nur eine Platte ausfällt, sind die Gesamtdaten aus den verbleibenden Platten nicht mehr vollständig herzustellen. Also schreiben wird doch all unsere Dateien einfach immer gleichzeitig parallel auf mehrere gleichgroße Platten. Dann können Platten ausfallen, solange aber noch eine Platte ok ist, sind unsere Daten alle noch vollständig verfügbar. Unsere Gesamtkapazität ist dann allerdings nur noch genauso groß wie die Einzelkapazität der Platten selbst. Damit haben wir so ziemlich das Gegenteil von RAID 0 und einen neuen RAIDLEVEL definiert '''RAID 1''' auch Mirroring also Spiegelung genannt, auf mehreren Platten stehen Bitgenau immer die selben Daten. 

Eine andere Möglichkeit, wir schreiben unsere Daten wie bei RAID 0 in Streifen auf mehrere Platten, und auf eine zusätzliche Platte schreiben wir die [http://de.wikipedia.org/wiki/Parit%C3%A4tsbit Parität], also eine Bitweise Verknüpfung der einzelnen Blöcke auf den einzelnen Platten. Jetzt kann eine Platte ausfallen, ist es die zusätzliche sind die Daten alle noch heil, ist es jedoch eine der anderen Platten, dann können wir aus den Daten der verbleibenden Platten und dem Vergleich mit dem Inhalt der zusätzlichen Platte den Dateninhalt der defekten Platte wieder genau rekonstruieren. Dazu benötigen wir zwar etwas Rechenleistung beim Schreiben sowie beim Auslesen wenn einen Platte defekt ist, aber wir haben eine Gesamtkapazität von (Anzahl der Platten-1) x Einzelkapazität und eine Redundanz von genau einer Platte. Und schon haben wir einen neuen RAIDLEVEL definiert RAID 3. 

Von solchen RAIDLEVELN gibt es eine ganze Reihe die alle mehr oder weniger verschiedene Eigenschaften haben. Nachzulesen zB bei [http://de.wikipedia.org/wiki/RAID#Die_gebr.C3.A4uchlichen_RAID-Level_im_Einzelnen Wikipedia ]. Auch ist es möglich so entstandene RAIDs dann in weiteren RAIDs einzubinden und so die Stärken und Schwächen der einzelnen RAIDLEVEL zu kombinieren, um somit große Plattenkapazitäten mit speziellen RAID-Eigenschaften darzustellen.

Gemeinsam allen RAIDs ist, es wird eine logischer Verbund mehrerer physikalischer Platten erzeugt. Der Rechner arbeitet dann mit dem logischen Verbund als Ganzes genau so, als währe es eine einzelne physikalische Platte.

=== RAID ist nicht immer gleich RAID ===

Zwar ist mit dem RAIDLEVEL schon das wichtigste Kriterium für die Raideigenschaften festgelegt, jedoch ist ein RAID nicht immer das selbe RAID nur weil es den selben RAIDLEVEL hat. Es gibt eine Reihe von weiteren Eigenschaften die die Leistungsfähigkeit, insbesondere den Datendurchsatz innerhalb eines RAID positiv oder negativ beeinflussen können, auch wenn die Gesamtstruktur gleich ist. Angenommen wir haben ein RAID1 auf 2 Platten. Also gespiegelt. Beim Schreiben müssen die selben Daten sowohl auf die eine, wie auch auf die andere Platte geschrieben werden. Also die langsamste Platte bestimmt die maximale Schreibgeschwindigkeit. Jetzt kommt hier so ein Raidcontroller daher und sagt, ich warte aber nicht bis die Daten auf der Platte stehen, sondern melde schon "fertig" zurück, wenn ich die Daten erstmal nur in einem Speicher zwischengespeichert habe, auf Platte speichere ich wenn ich Zeit dazu habe. Na, wenn das mal gut geht. Oder beim Lesen desselben. Welche Platte ich lese ist ja egal, also lese ich immer die erste Platte solange diese ok ist. Ein anderes Raidkonzept sagt sich, wenn beide ok sind, dann lese ich doch die ersten 4 zusammenhängenden Blöcke von Platte 1 und fordere gleichzeitig schon mal die nächsten 4 Blöcke von Platte 2 an, sollten diese dann jetzt gleich angefordert werden, habe ich die schon fix und fertig auf Vorrat da.

=== der kleine Unterschied ===

Zum Betreiben eines RAIDs benötigen wir also neben mindestens 2 Platten auch eine gewisse Logik und in vielen Fällen sogar mehr oder weniger Rechenleistung die dahinter steckt. Diese Logik läßt sich nun in Form eines Treibers recht schnell vor den Zugriff auf die Einzelplatten innerhalb des Betriebssystems dazwischenschieben. Und schon haben wir einen neuen Begriff, '''Softwareraid''' Die gesamte Verwaltung und Steuerung übernimmt das Betriebssystem selbst. Wir sprechen nur dem RAID-Treiber an, und dieser verteilt unsere Daten und Aufträge dann entsprechend über die Funktionen des Betriebssystems auf die einzelnen Platten. Das hat eine ganze Menge Vorteile, aber auch einige nicht zu übersehende Nachteile. 

Eine andere Möglichkeit, wir lagern die gesamte Logik mit samt der Plattencontroller und den Festplatten aus. Dazu brauchen wir einen Stück eigenständige Hardware die mindestens einen eigenen Plattencontroller besitzt, an dem dann mindestens 2 Platten angeschlossen werden. Diese Hardware benötigt ein eigenes Rechenwerk, um die Ansteuerlogik und Rechenarbeit für das RAID zu bewältigen. Selbstverständlich wird auch noch eine Schnittstelle für unseren Rechner benötigt, damit wir vom Rechner aus auch darauf zugreifen können. Quasi brauchen wir einen kleinen möglichst selbständigen arbeitenden Minicomputer der nur dazu da ist, unsere RAID-Platten zu betreiben und der irgendwie mit unserem Betriebssystem verbunden ist. Und schon haben wir '''Hardwareraid'''. Das Betriebssystem braucht jetzt gar nicht mehr mit den einzelnen Platten selbst zu arbeiten, ja es sieht sie nicht einmal mehr. Dafür gaukelt das Hardwareraid unserem Betriebssystem eine physikalische Platte vor, die in Wirklichkeit jedoch eine logische Platte aus mehreren physikalischen Platten ist, das weiß aber nur das Hardwareraid selbst, nicht unser Betriebsystem. Die benötigte Rechenleistung für das RAID, und die Ansteuerung der Platten und des Plattencontrollers wird einzig und allein vom Rechenwerk des Hardwareraids getragen. Dieses Hardwareraid könnten wir jetzt mit vielen Platten in einen eigenes Gehäuse bauen und zB über eine Netzwerk an unseren Rechner anschließen und schon haben wir ein [http://de.wikipedia.org/wiki/Festplattensubsystem Disk-Array]. Oder aber wir könnten das auch etwas kleiner gebaut, mit einem so genannten Raid-Controller-Chip bestückt in Form eines eigenständigen Controllers in den PCI-Bus stecken und die Platten dennoch im Rechnergehäuse unterbringen und schon haben wir einen [http://en.wikipedia.org/wiki/RAID_controller Hardware-RAID-Controller]. Aber auch das Hardwareraid hat Vor- und Nachteile 

Software RAID ist immer etwas kompliziert in der Handhabung während des frühen Boot-Prozesses, auch ist es in der Regel absolut unpraktisch bei Desktop-Version von Windows. Hardware-RAID-Controller sind jedoch teuer. Um diese Lücke zu schließen, wurden in den letzten Jahren preiswerte "RAID-Controller" erfunden und eingeführt. Diese enthalten jedoch keinen vollwertigen RAID-Controller-Chip, sondern lediglich einen Standard-Festplatten-Controller-Chip mit spezieller Firmware. Implementiert sind oftmals nur RAID 0 und RAID 1. Während der frühen Phase des Bootvorgangs wird dieses RAID von der Firmware dieses Festplatten-Controllers gestützt, wenn jedoch das Betriebssystem geladen ist, muss das Betriebssystem über einen Treiber selbst das RAID betreiben. Es handelt sich also um Softwareraid mit BIOS- oder Firmwareunterstützung. 
Diese Art RAID ist meistens direkt auf den Mainboards verbaut und wird durch die Hersteller als RAID-Controllern verkauft. Es wird selten wirklich deutlich gemacht, dass die Belastung der Raidverarbeitung dabei durch die CPU des Rechners und nicht etwa durch den RAID-Controller selbst getragen wird. In technisch fachkundigen Kreisen und in der Linuxwelt wird diese Art RAID oftmals als '''Fake-RAID''' bezeichnet.

=== Wozu benötigen wird den RAID heute ===

Die Entwicklung von RAID hat sich ja vornehmlich in den Rechenzentren vollzogen, Erst waren die Platten zu teuer, dann zu klein, dann waren die Controller zu langsam, irgendwann waren dann die Platten nicht mehr schnell genug usw. Viele dieser Probleme stellen sich heute in den Rechnenzentren nicht mehr ganz so vordergründig dar. Beim Einsatz von RAID geht es dort heute vielmehr in erster Linie um Rechnerverfügbarkeit und Ausfallsicherheit. Was ist damit gemeint. Eine einzelne Platte wird zwangsläufig irgendwann versagen, ob sie durch Schreib-Lesefehler auffällt, durch versagen der Elektronik oder Motorstillstand ausfällt, ob es in 10 Jahren, morgen früh, oder nach dem nächsten Reboot ? Von einer einzelnen Platte kann man das nicht vorhersagen. Wir haben ein Risiko X. Haben wird 4 Platten, dann haben wir das Risiko 4X und haben wir 1000 Platten, dann haben wir das Risiko 1000X. Und irgendwann fällt uns auf, wir haben jetzt im Durchschnitt in der Woche oder im Monat so und so viele defekte Platten, Wir haben eine Ausfallwahrscheinlichkeit aber können nicht bestimmen welche Platte im einzelnen oder speziellen als nächste ausfallen wird. Nun hat man aber nicht wie vielleicht mit dem eigenem Laptop die Möglichkeit wegen jeder Kleinigkeit den Rechner anzuhalten oder zu rebooten, das bedeutet das System und die Applikation müssen ganz normal weiterlaufen auch wenn eine Platte defekt ist, und die Platte muss sich im laufenden Betrieb durch eine neue ersetzen lassen und danach muss sie wieder so integriert werden, das ein erneuter Plattenausfall auftreten darf. 

Im anderem Extrem, dem privaten Umfeld auf einem normalem Desktop sieht es etwas anders aus, Hier habe ich sowieso nicht die Möglichkeit ein Platte im laufenden Betrieb zu tauschen, zu was auch, ich schalte den Rechner täglich sowieso mehrmals aus, und wegen jeder Mausbewegung muss ich den Rechner sowieso rebooten, damit die Änderung wirksam wird. Über Hoch-Verfügbarkeit brauchen wir hier nicht reden. Versuchen wir es mit Ausfallsicherheit. Auch hier wird über kurz oder lang mal eine Platte ausfallen. Wie wichtig ist es jetzt das der Rechner weiterläuft und ich das gar nicht mitbekomme? Währe es hier nicht besser der Rechner würde abstürzen und ich somit bemerken das eine Platte defekt ist? Ich möchte sogar frech behaupten, viele die irgendwann einmal auf LINUX ein Softwareraid auf ihren privaten Rechner installiert haben, haben weder die Raidfunktionen auf alle möglichen Ausfallkriterien getestet noch sich seit dem jemals wieder um den Zustand und die Konsistenz ihres RAID gekümmert. 
Es ist zwar schön zu wissen, wenn eine Platte beim Einschalten ausgefallen, tot oder halbtot ist, dann könnte ich normalerweise trotzdem normal booten und weiter arbeiten, mir müssten nur mal schnell die Befehle wieder einfallen, um auch von der 2. Platte booten zu können oder die defekte Platte auszukonfigurieren damit sie mir nicht noch länger das gesammte System ausbremst. In diesem Umfeld ist es also nicht ganz ausgeschlossen, dass man entweder wochenlang schon defekte Platten im Rechner hat, ohne es zu merken, oder mit einer defekten Platte trotz RAID nicht normal arbeiten kann, weil zB im RAID-Desing Fehler gemacht wurden. Manch einer wird feststellen, dass eine Neuinstallation oder das Einspielen eines Backup schneller ist, als ungeübt die Reparatur eines defekten Raids durchzuführen. Das geht schon los, 80GB SATA Platte defekt, 80GB SATA Platte eines anderen Herstellers eingebaut da die orginal Platte nicht mehr auftreibbar. Ergebniss nach 2 Stunden suchen nach der Ursache warum das RAID nicht synchronisieren will, Platte zu klein 76GB will das RAID sehen, sieht aber nur 74GB. Und nun? 
Ein Backup kann mir das RAID auch nicht ersetzen, zuwas also hier RAID? 
Ich kann hier wunderbar die anderen Eigenschaften die RAID hat, versuchen für mich auszunutzen.
Billige kleine Platten zu größeren Raidplatten zusammenbauen, wenn es sich wirklich rechnet ist das mit RAID das kleinste Problem, meist ist es aber so, dass eine doppelt so große Platte in der Neuanschaffung nur 30% teurer ist. Die Datenzugriffszeit verbessern, gute Idee, und wird in der Praxis auch in einem gewissen Umfang durch RAID machbar sein, wer allerdings der Meinung ist durch RAID 0 über 4 Platten würde LINUX dann plötzlich in Lichtgeschwindigkeit booten, wird feststellen, das hier eine ganze Reihe von weiteren Faktoren mitspielen, die ohne ein tieferes Verständnis so einfach überhaupt nicht zu optimieren sind. 

Bleibt noch der große Bereich zwischen Rechenzentrum und privatem PC. Hier wird man aus zum Teil ganz unterschiedlichsten Gründen heute und in Zukunft ohne RAID nicht auskommen können. Derzeitige Entwicklungstendenzen und Innovationen im Hardware Bereich haben deshalb insbesondere solche Umgebungen ins Auge gefasst.

=== das Handling ===

RAID ist nun ob Hardware oder Software gestützt nicht die einfachste Technologie, insbesondere da wir uns auf die Funktionalität eines RAIDs 100% verlassen müssen.Im Softwareraidbereich sind oftmals für jedes Betriebssystem 1 oder 2 komplett unterschiedliche Raidkonzepte möglich, in zT. unterschiedlicher Ausprägung und Umfang, von ganz unterschiedlichen Firmen entwickelt und vertrieben. Jedes ist in sich geschlossen und weder Funktionen, Konfigurationsdateien, Tools noch Befehle, geschweige denn schon konfigurierte Platten oder RAIDs,lassen sich von einem auf das andere übertragen. Auf der Konsolzeile hat man zwar überall die 100%ige Kontrolle über das RAID, allerdings sind die Befehle und Optionen zT so kompliziert, dass man sehr viel Erfahrung dazu benötigt. Für viele Produkte gibt es Grafische Raidmanager die es auch einem weniger Geübten erlauben sollen, RAID zu erstellen und zu verwalten, oftmals jedoch sind diese Tools entweder zu primitiv oder viel zu kompliziert für genau den einen Zweck den man gerade benötigt. Problematisch ist oftmals das Online Austauschen von Platten, da hier in einigen Konzepten eine noch nicht ganz ausgefallene Platte erst einmal aus dem RAID-Verbund heraus muss, und hinterher wieder dazugefügt werden muss. Es ist auch nicht immer das einfachste der Welt eine Ersatzplatte eines anderen Types oder Herstellers problemlos einzutauschen, wird aber häufig benötigt. Da man mit Softwareraid sehr viele Freiheiten in der prinzipiellen Konzeption der RAIDs hat, die wenig oder gar nicht vom System überprüfbar sind, kann man durchaus auch schwerwiegende RAID-Desing Fehler einbauen.

Im Hardwareraid Bereich ist es mit der Hardware ähnlich. Jeder Hersteller, zT jedes Produkt manchmal sogar jeder einzelne Firmwarestand ist nicht mit dem anderen kompatibel, Sprich defekter Controllertype 32a vom Hersteller A muss wirklich durch genau diesen Controller manchmal auch noch mit einem speziellen oder mindest Firmwarestand ersetzt werden, damit die Daten hinterher auch wieder sichtbar sind. Schon fertig konfigurierte Platten von einem Controllertype in einen anderen Controllertype übernehmen, unmöglich. Hier wird es bei der derzeitigen Geschwindigkeit mit der neue Produkte auf den Markt erscheinen und wieder verschwinden zunehmend schwieriger über einen längeren Zeitraum Ersatz für einen eventuellen defekten Controller zu bekommen, Man ist also entweder auf Wartungsverträge angewiesen oder muss im Bedarfsfall Ersatz auch über spezielle Vertriebswege einkalkulieren, oder jedesmal bei einem Defekt das Raidkonzept ändern. Plattentausch auch unterschiedlicher Typen und Hersteller macht weniger Ärger. Dafür hat man vom Betriebssystem selbst überhaupt keine Kontrolle über das RAID. Eine Administration ist entweder nur im BIOS des Raidcontrollers also im Offlinemodus des Rechners möglich, oder über spezielle Grafische Raidmanager der Hersteller. Hier besteht insbesondere ein Problem für Linuxanwender, zwar sind diese Tools oftmals für Professionelle Distributionen verfügbar und freigegeben, allerdings auf vielen normalen Distributionen wird man nicht selten vergeblich versuchen, diese Tools zum laufen zu bekommen. Ähnlich verhält es sich mit der Überwachung und frühzeitigen Fehlererkennung, nicht immer erhält man hier auf "normalen" Linuxdistributionen die Meldungen die man gerne hätte. Die Controller erlauben zwar eine sehr genaue und sehr spezielle Konfiguration in einzelnen Parametern, jedoch durch die default Voreinstellungen und die strikte Führung bei der RAID-Erstellung sind schwerwiegende Fehler in der RAID-Konfiguration jedoch ehr die Ausnahme. Allerdings ist man immer an den Umfang der Möglichkeiten des RAID-Controllers gebunden, was mit Controller und Firmware nicht berücksichtigt ist, bleibt nicht machbar.

== Softwareraid ==

Softwareraid ist in der Anschaffung die preiswerteste Alternative. Es bietet die meisten Möglichkeiten und wenig Beschränkungen, da man nicht nur komplette Platten, sondern auch einzelne Partitionen einbinden und kombinieren kann. Auch ist das Anschlusskonzept der Platten völlig belanglos, man könnte also durchaus auch eine Parition einer IDE-Platte mit einer Partition einer SCSI-Platte und einem LOOP-Device und einem RAM-Device zu einem gemeinsamen RAID zusammenbauen. Der Konfiguration sind hier wenige Grenzen gesetzt. Softwareraid benötigt einen gewissen Teil der Systemresourcen, Das macht sich insbesondere bei rechenintensiven RAIDs wie RAID 5 oder RAID 6 bei hohem Datendurchsatz oder während des Rebuild des RAID durchaus bemerkbar. Darüber hinaus ist das Booten von einem RAID nicht in jedem Betriebssystem so einfach zu konfigurieren. Da das Betriebssystem jedoch auch die orginal Devices unterhalb des RAIDs sieht, sind Meldungen der einzelnen Platten ganz normal in den Logdateien zu finden, allerdings kann das RAID-Modul nicht verhindern, dass vom Betriebssystem aus eventuell auch unerwünscht und direkt auf die Plattenteile des RAID zugegriffen wird.
Von einigen Softwareraids bestimmter Betriebssysteme ist bekannt, dass sie nach einem Systemcrash oder ähnlichen die gesamten konfigurierten RAID wieder neu synchronisieren bzw rebuilden müssen, die zum Zeitpunkt des Crashes für Schreibzugriffe geöffnet waren. Bei großen Raidkonfigurationen kann so etwas nicht nur viel CPU- und IO- Belastung erzeugen, sondern auch recht lange dauern, in dieser Zeit ist das System nicht durch Redundante Daten vor Plattenausfällen geschützt, fällt hier die falsche Platte aus, stehen nicht nur Teile des Rechners sondern ich kann mir überlegen aktiviere ich die andere Platte in der Gewissheit das hier eventuell einige Bit falsch sein könnten, oder spiele ich gleich ein Backup ein. Handlingsfehler bei der Administration auf der Konsole sind bei Softwareraid ein nicht zu unterschätzendes Problem, das durchaus auch mal zu Datenverlust führen kann. Finetuning bei der Raidkonfiguration ist durchaus machbar, allerdings benötigt man für optimale bis maximale Ergebnisse einige Erfahrung und genaue Kenntnis des Systems und der genauen Umstände. Schwachpunkt des Softwareraids ist, fällt das System zB wegen eines Defektes plötzlich aus, können eventuell zu diesem Zeitpunkt zu schreibende Daten verloren gehen, bzw. dadurch unvollständiges Schreiben die Konsistens des Raids beeinträchtigt werden, wodurch ein teilweises bzw vollständiges rebuild des Raids notwendig würde. Begünstigend für solchen unerwünschten Datenverlust bei einem Absturz währe ein zusätzlich aktivierter Schreibcache auf den Festplatten.

== Hardwareraid ==

Echtes Hardwareraid kostet immer auch echtes Geld bei der Anschaffung und wird durch einen speziellen eigene Prozessor gestützt. Es werden private Plattencontroller und Busse benutzt, die für das Betriebssystem nicht zugänglich sind und sich ebenfalls mit auf dem Raidcontroller befinden. Zusätzlich sind meist noch Slots für Speichermodule als RAID-Cache sowie eine Batterie (BBU) zum stützen der sich in diesem Speicher befindlichen Daten optional möglich. Die volle Leistungsfähigkeit erreicht der Raidcontroller erst dadurch. Der Raidcontroller arbeitet selbstständig und völlig ohne jegliche Unterstützung eines Betriebssytems, es ist ihm also vollkommen egal ob dort ein Dos, Windows, Linux oder Solaris gerade die RAIDs benutzt. Einzig einen Treiber zum Ansprechen des Controllers muss es im Betriebssystem geben, die Unterstützung der gebäuchlichsten Raidcontroller im Linuxkernel ist zB recht gut und umfassend 
Raidcontroller gibt es hauptsächlich für SCSI, SATA, oder SAS Platten. Es können vom Controller aus nur die an diesem Controller angeschlossenen Platten verwaltet werden, einige wenige Contoller erlauben es auch RAID über mehrere baugleiche Controller zu erstellen. Durch die Nutzung des Cachespeichers in Kombination mit bestimmten Schreiboptionen ist es dem Raidcontroller möglich, eine Bestätigung für das Schreiben der Daten schon dann zu geben, wenn sich die Daten im Cache des Controllers befinden, also noch gar nicht physikalisch auf die Platten geschrieben sind. Ebenso können bestimmte Einstellungen beim Lesen von sequentiellen Datein durch Nutzung des Caches eine deutliche Durchsatzsteigerung bewirken. Die richtige Nutzung des Caches kann eine Leistungssteigerung von bis zu 50% bewirken. Fällt der Strom aus, und es befinden sich noch ungeschriebene Daten in diesem Cache, sorgt die Batterie dafür das diese für einige Stunden meist Tage nicht verloren gehen. Wird der Rechner eingeschaltet und der Controller aktiviert, werden diese Daten dann geschrieben. Es gehen dadurch auch beim Systemcrash uÄ keine Daten verloren und es werden dadurch auch die RAIDs nicht inkonsistent. Der Leistungsumfang und die Möglichkeiten sind in den einzelnen Controllern recht unterschiedlich und spiegeln sich nicht zuletzt auch im Preis wieder, gemeinsam ist ihnen jedoch begrenzte Konfigurationsmöglichkeiten und die Möglichkeit der Aktivierung und Deaktivierung sehr spezieller Funktionen.die zum Teil auch radikale Auswirkungen beim Datendurchsatz haben können. Fehlkonfiguration ist jedoch kaum möglich, solange man nur an den Feldern herumspielt von denen man sich der Bedeutung bewußt ist. Der Controller sorgt nicht nur selbst für die optimalsten Bedingungen und bedient und überwacht das RAID, er überwacht auch die Platten auf Unregelmäßigkeiten und Fehler. Inkonsitenzen und Fehler werden vom Controller selbst erkannt und gegebenenfalls auch mit Auskonfigurieren der verursachenden Platte geahntet. Inwieweit diese Fehler dann auch vom Betriebssystem abgegriffen werden können, hängt nicht zuletzt davon ab ob man spezielle Tools und Managementunterstützung der Hersteller auf seinem Rechner installiert hat oder nicht. Plattentausch ist unproblematisch, das Wiederherstellen des RAID regelt der Controller selbst. Hardwareraid ist also eine sehr leistungsfähige Methode die alle Vorteile von RAID optimal nutzen kann, außer die mit dem Preis.

=== Hardware Trends ===

Derzeit ist neben der weiter oben schon erwähnten Methode einfache Softwareraid basierende Funktionen auf dem Systemboard durch Firmware zu stützen auch eine verstärkte Aktivität zu verzeichnen, preiswertes richtiges Hardwareraid mit auf die Mainboards zu setzen. 
Dazu zählen einerseits vollwertige Raidcontroller-Chips inclusive Slot für Speichercache und BBU. So ein Board mit Vorbereitung für echtes Hardwareraid ist in der Anschaffung erst einmal vergleichsweise günstig, jedoch nicht immer auch so schon wirklich nutzbar. Es ist möglich, dass dieser Raidcontroller auf dem Systemboard erst durch einen separat zu kaufenden "Dongle" freigeschaltet wird. Der Dongle könnte aussehen wie eine etwas zu groß geratene BIOS-Batterie, und auch genauso einzubauen sein. In ihm befindet sich der Lizenzkey sowie die Konfigurationsdaten für das RAID. Auch der Speicher und die BBU ( Cachebatterie ) die für die volle Leistung des RAIDs notwendig währen, müssten optional erworben werden.

Eine andere Masche ist der sogenannte "Zero-Channel RAID Controller" Dabei handelt es sich um einen vollwertigen Raidcontroller der allerdings kein eigenen Plattencontroller beherrbergt. Statt dessen kann er aber die Plattencontroller auf dem Mainboard nutzen. Dieser Controller muss meist auf einen festgelegten PCI-Steckplatz betrieben werden. Einzige Einschränkung, die Daten müssen dabei zwei mal durch den PCI-Bus, Ein mal auf dem Weg zum Controller und dann von dort aus wieder zurück zu den Plattencontrollern.

== weitere Links==

* [http://de.wikipedia.org/wiki/RAID#RAID_1E RAID Wikipedia]
* [http://www.tecchannel.de/storage/grundlagen/401665 RAID Grundlagen]
* [http://www.tecchannel.de/storage/san/432631 Praxis-Know-how: RAID-Controller optimal konfigurieren]
* [http://www.raid-controller.info www.raid-controller.info]
* [https://wikibs.informatik.htw-dresden.de/swiki/index.php?title=Software-RAID&printable=yes Howto Software-RAID mit Linux]
* [http://de.gentoo-wiki.com/Raid_5_Verbund_mit_mdadm_erstellen Raid 5 mit mdadm]

-----

[[Allgemeines | Zurück zu Allgemeines]]

[[Category:Allgemeines]]