Skip to topic | Skip to bottom
Linux.UnixPermissionsr1.1 - 01 Mar 2011 - 13:19 - TWikiGuest? [Zum Ende]

Start of topic | Direkt zum Menü

Datei-/Verzeichnisrechte unter Unix-Betriebssystemen

von FrankBurkhardt

Das Unix-Dateisystem in 10 Minuten erklärt

Nur ein Baum, kein Wald

Im Gegensatz zu anderen Betriebssystemen und Plattformen (z.B. DOS, Windows, MacOS ohne X) existiert unter Unix-Betriebsystemen nur ein Verzeichnisbaum. Es gibt nur ein Grundverzeichnis ( "/" ) und nicht viele (z.B. unter DOS: "A:\", "C:\", "D:\" ). Das macht viele Dinge einfacher. Jedes laufende Programm besitzt genau ein "aktuelles Verzeichnis" ( current working directory ).

Das Dateisystem unter Unix ist baumförmig aufgebaut. Wenn also ein Programm alle Verzeichnisse einlesen will, kann es eine Breiten- bzw. Tiefensuche machen und muss nicht überprüfen, ob es dabei evtl. im Kreis sucht. Diese Regel wird derzeitig nur durch verteilte Netzwerkdateisysteme ( z.B. AFS und DFS ) gebrochen.

In dem Baum aus Verzeichnissen können sich Dateisystemobjekte befinden, die jeweils einem Besitzer gehören. Jedem dieser Objekte ist außerdem eine Gruppe (von Benutzern) sowie bestimmte Rechte für den Besitzer, die Gruppe sowie den "Rest der Welt" zugeordnet. Ein einem solchen Objekt hängen noch weitere Informationen (z.B. Zeitstempel), die jedoch nicht mit Zugriffsrechten zu tun haben.

Dateisystemobjekte

Unter vielen Plattformen (z.B. DOS) existieren nur 2 Dateisystemobjekttypen (Dateien, Verzeichnisse). Da unter Unix viele Aktionen, wie der Zugriff auf Geräte (z.B. Soundkarten oder Scanner) oder die Kommunikation zwischen Programmen über das Dateisystem abgewickelt werden, kennt es weitere Objekttypen. Dies ist die Liste der möglichen Typen:

Objekttyp Symbol1 down Symbol2 Erklärung
Datei -   Dateien sind unter Unix lediglich Datenströme. Im Gegensatz z.B. zu MacOS? kennt das Betriebssystem nicht die interne Struktur von Dateien. Lediglich die Grösse ist dem Betriebsystem bekannt. Jeder Datei ist im Gegensatz z.B. zu WindowsNT? immer genau ein Datenstrom zugeordnet.
Block-Device b   Diese Objekte erlauben den Zugriff auf Geräte, wobei (zur Zugriffsbeschleunigung) der Block-Puffer des Betriebssystems verwendet wird. Anhand zweier Nummern (Major-, Minor-Number) wird das referenzierte Gerät durch den Kernel identifiziert. Das Lesen- bzw. Schreiben auf ein solches Dateisystemobjekt entspricht der Eingabe von bzw. der Ausgabe an ein Gerät (z.B. eine Diskette). Massenspeichergeräte auf denen direkt addressierbare Daten liegen (z.B. Festplatten, Disketten, CDROMs, ...) werden durch solche Block-Devices angesprochen.
Character-Device c   Solche Objekte verhalten sich mit einer Ausnahme wir Block-Devices: Gelesene oder geschriebene Daten werden nicht im Block-Puffer zwischengespeichert. Das ist die fuer alle Geraete sinnvoll, die nicht als direkt addressierbarer Massenspeicher dienen (Scanner, Drucker, ...)
Verzeichnis d / Verzeichnisse sind die einzigen Dateisystemobjekte, deren Struktur Unix kennt. Es sind Listen aus sog. Dentries. Jedes Verzeichnis enthält mindestens 2 solche Eintraege ( "." und ".." ).
Symbolischer Link l @ Symbolische Links sind Zeiger auf Dateisystemobjekte. Wird ein symbolischer Link geoeffnet, dann wird dieser Zugriff vom Betriebsystem auf das Ziel dieses Links umgelenkt. Bis zu einer gewissen Tiefe werden auch symbolische Links verfolgt, die auf symbolische Links verweisen.
Named Pipe p | Diese Objekte werden benutzt, um Daten zwischen 2 Prozessen auszutauschen. Dazu öffnet ein Prozess die Pipe zum Lesen, der andere zum Schreiben. Alle Daten, die der Schreibprozess in die Pipe schickt, kommen beim Leseprozess an. Pipes sind die einfachste Form der Prozesskommunikation unter Unix. Es existieren auch "Pipes ohne Namen", die haben jedoch nicht direkt mit dem Dateisystem zu tun.
Socket s = Sockets werden von Prozessen benutzt, die bestimmte Serverdienste einer potentiell grossen Zahl von anderen Prozessen zur Verfuegung stellen wollen. Das Prinzip ist aehnlich dem, das von Netzwerk-Serverprozessen (z.B. Webservern) benutzt wird, um mehrere Verbindungen gleichzeitig bedienen zu können. Bei diesen Sockets findet jedoch keine Netzwerkkommunikation stat.

Benutzt man die -l -Option des ls-Kommandos, so wird der Typ des Dateisystemobjektes als erstes Zeichen vor den Modebits ( Symbol1 ) angezeigt (i.d.R. als erstes Zeichen der Zeile). Benutzt man die -F -Option des ls-Kommandos, so wird fuer einige Dateisystemobjekttypen das entsprechende Symbol hinter dem Dateinamen angezeigt ( Symbol2 ). Ausführbare Dateien werden mit einem Stern markiert. Hier ein Beispiel:
user@host > ls -laF /dev/zero /dev/gpmdata /etc/fstab
prw-r--r--  1 root root   0 2004-12-15 16:37 "/dev/gpmdata" |
-rw-r--r--  1 root root 318 2004-05-22 19:09 "/etc/fstab"
crw-rw-rw-  1 root root 1, 5 2004-08-20 09:43 "/dev/zero"
/dev/gpmdata ist eine Named Pipe , /etc/fstab ist eine normale Datei. /dev/zero ist ein character Device. Die Nummerm ( 1, 5 ) identifizieren das Gerät - d.h. der Kernel interessiert sich nur für diese beiden Zahlen, nicht für den Dateinamen.

Inodes und Dentries

Im Gegensatz zu anderen Betriebsystemen und Plattformen (z.B. DOS) kann eine Datei unter Unix nicht nur genau einen Namen haben (in bestimmten Fällen haben bestimmte Dateien überhaupt keinen Namen). Spricht man von einer Datei, meint man normalerweise einen Inode , eine Datenstruktur, die Daten wie den Besitzer, die Gruppe, die Permissions, die Zugriffszeiten (im Prinzip alles, was der stat() -Systemaufruf zurückliefert) sowie einen Zeiger auf die eigentlich Daten enthält.

In den Verzeichnissen des Dateisystems befinden sich nun keine Inodes sondern Dentries. Ein Dentry ist ein Zeiger auf genau einen Inode. Beliebig viele Dentries (es gibt bestimmt eine Grenze nach oben, aber mir ist keine bekannt :-) ) können auf einen Inode zeigen.

Legt man eine Datei an, so erzeugt das Betriebssystem einen Inode sowie einen darauf zeigenden Dentry. Es ist möglich, weitere Dentries, die auf einen Inode zeigen, anzulegen. Um das zu machen, braucht man nicht einmal Zugriffsrechte auf die Datei (also auf den Inode), man muss nur in das Verzeichnis schreiben dürfen, in dem der Dentry angelegt werden soll. Außerdem muss man sich den Inhalt eines Verzeichnisses anzeigen lassen dürfen, das einen Dentry enthält, der auf die gewünschte Datei zeigt.

Unter Unix kann man eine Datei (also einen Inode) nicht direkt löschen, man kann nur Dentries entfernen. Entfernt man den letzten Dentry, der auf einen bestimmten Inode zeigt, wird der Inode automatisch gelöscht. Greift dann allerdings gerade ein Prozess auf die Datei zu (sprich: hält ein Prozess die Datei offen, während der letzte Dentry entfernt wird), so wird der Inode erst entfernt (und der Speicher der Datei freigegeben), wenn der Prozess die Datei schließt. Bis die Datei geschlossen wird, existiert sie dann zwar noch, hat jedoch keinen Namen mehr.

Standard-Unix-Permission-Bits

Root darf alles

Benutzer mit der User-ID 0 sind die Superuser unter Unix-Betriebssystemen. Es kann davon mehrere geben (also mehrere Benutzernamen, die zur UID aufgelöst eine 0 ergeben), i.d.R. existiert allerdings nur einer ( root ). Für root gelten die Standard-Permission-Bits nicht, wenn auch manche Programme sie explizit überprüfen (z.B. rm beim Löschen von Dateien). Superuser haben immer volle Rechte auf Dateisystemobjekte. Diese Regel kann nur durch den Einsatz von Netzwerkdateisystemen, die sich nicht 100-prozentig an den Unix-Standard halten oder durch spezielle Erweiterungen am Betriebssystem außer Kraft gesetzt werden.

Eine kleine Ausnahme sind die x-Bits. Fehlt das x-Bit an einer Datei, kann auch Root diese nicht ausführen.

Man sollte sich des weiteren im klaren darüber sein, daß jeder, der physischen Zugriff auf einen Computer hat, ebenfalls alles darf. Es ist schließlich möglich, eine Boot-CD einzulegen und auf Sekundärspeichermedien (z.B. Festplatten) unter Umgehung der Kontrolle des eigentlich installierten Betriebssystems zuzugreifen. Daten kann man vor einem solchen Zugriff nur durch Verschlüsselung schützen und selbst das kann gegen einen lokalen Angreifer nicht 100%ig sicher sein.

Rechte werden nur beim Öffnen/Ausführen der Datei geprüft

Wenn ein Benutzer eine Datei öffnet, kann er mit dieser Datei arbeiten. Daran ändert sich nichts, wenn die Rechte der Datei danach verändert werden, ein anderer Besitzer gesetzt, oder die Datei sogar gelöscht wird. für Netzwerkdateisysteme gilt diese Regel nicht.

Der Zugriff bleibt auch dann erhalten wenn sich der Besitzer des Prozesses ändert, der die Datei offen hält. Solche Benutzerwechsel sind allerdings nur möglich, wenn die Datei als root geöffnet oder eine mit einem SetUID? bzw. SetGID?-Bit versehene Datei, die root gehört, ausgefuehrt wurde. Das liegt daran, dass nur root in der Lage ist, einem laufenden Prozess einen neuen Besitzer zuzuweisen.

Symbol Oktal Bedeutung für Dateien Bedeutung für Verzeichnisse
r 4 Dieses Recht ermöglicht das Auslesen des Inhalts einer Datei. r ermöglicht das Auslesen der Eintraege eines Verzeichnisses (also z.B. das Ausfuehren des ls-Befehls). Um dieses Recht einsetzen zu können muss man auch das x-Recht des Verzeichnisses inne haben.
Hinweis: Das Leserecht auf ein Verzeichnis hat absolut gar nichts damit zu tun, ob man Dateien in diesem Verzeichnis lesen darf.
w 2 Mit diesem Recht kann man Daten in eine Datei schreiben (direkt hineinschreiben und anfuegen). Es umfasst nicht das Loeschen von Dentries. Dazu muesste Schreibrecht auf das Verzeichnis, das den Dentry enthaelt, gewährt werden. Durch das w-Recht erhält man die Moeglichkeit, Dentries eines Verzeichnisses zu manipulieren. Dazu zaehlen folgende Aktionen:
  • Dateien, Symlinks oder Pipes anlegen (Devices-Files kann nur root anlegen)
  • Dateien loeschen (=Dentries unlinken)
  • Dateien umbenennen (bzw. Dateien verschieben)
  • Zusaetzliche harte Links erzeugen (mit dem ln-Befehl)
x 1 Ist dieses Recht fuer eine Datei verfügbar, so kann sie durch einfaches aufrufen in der bash (also durch einen exec()-Systemaufruf) ausgefuehrt werden. Das ist bei Programmen im Maschinencode ("binaries") sowie bei Skripten sinnvoll. Unix entscheidet ueber die Ausfuehrbarkeit einer Datei durch dieses Bit. Dadurch laesst sich das Ausfuehren von Programmen benutzergruppenspezifisch steuern. Ist dieses Recht gewährt, kann man in das entsprechende Verzeichnis wechseln.
Hinweis: Will man in ein durch einen Pfad angegebenes Verzeichnis wechseln, so muss man das x-Recht fuer alle Verzeichnisse in diesem Pfad besitzen.

Hinweise:

  • Für das Ausführen eines binären Programmes ist kein Leserecht nötig. Diese Tatsache wird gelegentlich als (zweifelhafte) "Sicherheitsoption" benutzt ("Benutzer darf Programm ausführen, jedoch nicht wissen, was es macht").
  • Für das Ausführen von Skripten (also von Dateien, deren Inhalt mit !# beginnt) sind immer auch Leserechte zum Ausführen nötig.

Jeder Datei und jedem Verzeichnis sind ein Besitzer und eine Gruppe zugeordnet. Die 3 Rechte koennen jeweils unabhaengig dem Benutzer, der Gruppe und dem "Rest der Welt" zugeordnet werden. Die Rechte schreibt man dann in der Form rwxrwxrwx, wobei die Reihenfolge der Bedeutung "Benutzer"/"Gruppe"/"Rest der Welt" ist.

Hier einige Beispiele:

drwxrwxr-x    2 burk     users          38 Apr  8 08:55 "."/
drwxrwxrwt    6 burk     users        4096 Apr  8 08:42 ".."/
-rw-r--r--    1 burk     users           0 Apr  8 08:42 "1"
-rw-rw-rw-    1 burk     users           0 Apr  8 08:42 "2"
----------    1 burk     users           0 Apr  8 08:42 "3"
-rw--w----    1 burk     users           0 Apr  8 08:55 "4"

Die Datei "1" darf von der ganzen Welt gelesen, jedoch nur vom Benutzer ("burk") geschrieben werden. "2" darf von absolut allen Benutzer gelesen und veraendert werden. Auf die Datei "3" hat keiner Zugriff. "4" darf vom Benutzer gelesen und veraendert werden. Zusaetzlich darf die Gruppe die Datei veraendern, jedoch nicht aus ihr lesen. Ausserdem darf die ganze Welt in das Verzeichnis wechseln und sich die Dateien auflisten lassen, jedoch nur der Besitzer und Gruppenmitglieder duerfen das Verzeichnis veraenden.

Rechte werden oft durch oktale Zahlen dargestellt. Den Zahlenwert mehrere Rechte erhaelt man durch Addition (korrekter waere "oder"-Verknuepfung) der einzelnen Rechte. Die folgende Tabelle zeigt die oktalen Werte fuer alle Gruppen und alle Bits, sowie die entsprechenden chmod-Parameter

Begünstigter r w x Alle zusammen
Besitzer der Datei 00400, u+r 00200, u+w 00100, u+x 00700, u+rwx
Gruppe 00040, g+r 00020, g+w 00010, g+x 00070, g+rwx
Rest der Welt 00004, o+r 00002, o+w 00001, o+x 00007, o+rwx
Die ganze Welt 00444, a+r 00222, a+w 00111, a+x 00777, a+rwx

Die "rwx"-Triplets von "Benutzer", "Gruppe" und "Rest der Welt" entsprechen jeweils einer Ziffer der oktalen Darstellung. Die Rechte der Datei "1" waeren dann in diesem Beispiel 00644.

Standard-Rechte unter Unix sind immer positiv. Wenn man also z.B. der Besitzer folgender Datei ist (also "burk") und zur Gruppe "users" gehört,

----rw----    1 burk     users           0 Apr  8 08:55 "5"

darf man trotzdem Lese- und Schreiboperationen an der Datei durchführen, "burk" jedoch nicht direkt. Ist "burk" jedoch Mitglied der Gruppe "users", darf er trotzdem zugreifen.

Es gibt keine Moeglichkeit, einem Nutzer oder einer Gruppe explizit ein Recht abzuerkennen. So etwas ist unter Unix nur durch "Nicht-erteilen" möglich. Das Dateisystem AFS kennt dagegen z.B negative Rechte.

Hinweise:

  • Einem Dateisystemobjekt ist nicht der Name des Benutzers/der Gruppe zugeordnet, sondern die entsprechende UID/GID. Der Namensdienst der libc kümmert darum, dass z.B. bei ls -la die Klartextnamen von Benutzer und Gruppe angezeigt werden und nicht wie z.B. bei ls -lan nur dir IDs.
  • Setzt man u-w auf eigene Dateien, so verhindert man, diese aus Versehen mit rm zu loeschen. rm fragt dann (zumindest unter Linux) nach, ob es derartige Dateien trotzdem loeschen (sprich: das u+w-Bit setzen und die Datei dann unlinken) soll.
  • Man kann Rechte absolut (z.B. chmod 777 datei.dat ), jedoch auch relativ (z.B. "chmod a+rwx") setzen. Das Manual von chmod ( man chmod ) erklärt das genauer.

Zusätzliche Standardrechte

Bit chmod Oktal ls Bedeutung für Dateien Bedeutung für Verzeichnisse
Sticky-Bit mit o+x +t,o+x 01001 ---------t Bestimmte Unix-Systeme halten Dateien, die dieses Bit innehaben und ausgefuehrt werden, unter allen Umstaenden im Blockpuffer. Dadurch erfolgt der Zugriff auf solche Programme i.d.R. schneller. Unter Linux hat dieses Bit an Dateien keine Bedeutung Dieses Recht bedeutet, dass in einem Verzeichnis Dateien nur durch deren Besitzer sowie durch den Besitzer des Verzeichnisses geloescht werden dürfen. Das /tmp -Verzeichnis benutzt z.B. dieses Bit
Sticky-Bit ohne o+x +t,o-x 01000 ---------T ? ?
SetUID? u+s,u+x 04100 ---s------ Mit SetUID? markierte Dateien werden mit den Benutzerrechten des Besitzers der Datei ausgeführt.
Hinweis: Unter den meisten Betriebssystemen (auch unter Linux) ist es aus Sicherheitsgründen wirkungslos, dieses Bit fuer Skripte zu setzen.
?
SetUID? ohne u+x u+s,u-x 04000 ---S------ ? ?
SetGID? g+s,g+x 02010 ------s--- Ähnlich wie das "SetUID"-Bit bewirkt dieses Bit, dass beim Ausfuehren dieser Datei die ihr zugeordnete Gruppe in die Gruppenliste des Prozesses eingetragen wird. Das Programm läuft dann also mit den Rechten dieser Gruppe.
Hinweis: Unter den meisten Betriebssystemen (auch unter Linux) ist es aus Sicherheitsgruenden wirkungslos, dieses Bit fuer Skripte zu setzen.
Legen Benutzer in einem Verzeichnis, an dem dieses Bit gesetzt ist, neue Dateisystemobjekte an, so wird die Gruppe dieser Objekt automatisch auf die Gruppe des Verzeichnisses gesetzt.
SetGID? ohne g+x g+s,g-x 02000 ------S--- ? ?

Wer darf welche Rechte ändern?

Jeder Datei und jedem Verzeichnis sind ein Besitzer und eine Gruppe zugeordnet. Legt man eine Datei oder ein Verzeichnis an, so wird man selbst zum Besitzer. Als Gruppe wird die eigene gid (die eigene primaere Gruppe) gesetzt. man kann Mitglied mehrer Gruppen sein. Die primaere Gruppe wird meist in der Datei /etc/passwd, andere Gruppenmitgliedschaften in der Datei /etc/group definiert. Man kann die eigenen Gruppenmitgliedschaften mit dem Kommando "id" anzeigen lassen. Jedes laufende Programm hat unter Linux eine Eigenschaft, die bestimmt, welche Rechte bei neu erstellten Dateien gesetzt werden: die umask. Mit dem gleichnamigen Kommando kann man sich diese auf einer Shell anzeigen lassen und auch setzen. I.d.R. ist sie auf 0022 eingestellt. Es ist zu beachten, dass die Bits der umask in den Permissions des neuen Dateisystemobjektes geloescht, nicht gesetzt werden, was bedeutet, dass eine neu angelegte Datei (bei einer umask von 0022) z.B. so aussieht:

-rw-r--r--    1 burk     users           5 Apr  8 10:19 "5"
drwxr-xr-x    2 burk     users           0 Apr  8 10:20 "x"/

Die w -Rechte der Gruppe (0020) sowie vom "Rest der Welt" (0002) sind nicht gesetzt. Bei der neuen Datei fehlen ausserdem noch die x -Rechte - das ist Standard. "x"-Rechte werden nur bei neuen Verzeichnissen gesetzt (wenn das nicht durch die umask eingeschraenkt ist).

Jeder Benutzer darf die elementaren Rechte sowie die zusätzlichen Standardrechte von Dateiensystemobjekten, deren Besitzer er ist, beliebig aendern. Einzige Ausnahme bilden die symbolischen Links. Da es nutzlos waere, deren Rechte zu aendern, ist das (zumindest unter Linux) nicht moeglich.

Jeder Besitzer einer Datei darf diese an jemand anderen übertragen (also den Besitzer ändern). Das darf jedoch nur der Besitzer - eine Mitgliedschaft in der zur Datei gehörigen Gruppe reicht dazu nicht aus.

Erreichbarkeit eines Objektes im Verzeichnisbaum

Ein Objekt ist dann erreichbar, wenn man in das Verzeichnis wechseln kann, das das Objekt enthaelt. Durch die Inode-Abstraktion kann ein Objekt Dentries in verschiedenen Verzeichnissen haben. Kann man in mindestens eines dieser Verzeichnisse wechseln, reicht das aus.

Natürlich sind nicht alle Dateien/Verzeichnisse für alle Benutzer gleichermaßen erreichbar.

Beachten Sie den Unterschied zwischen "Man muss in das Verzeichnis wechseln können" und "Das Verzeichnis der Datei muss das x-Recht haben". Schliesslich kann man das Verzeichnis, in dem die Datei liegt, nur durch das übergeordnete Verzeichnis erreichen. Es müssen i.d.R. alle Verzeichnisse des Pfades der Datei das "x"-Recht bieten.

Es gibt Ausnahmen wie z.B., dass root in ein fuer einen Benutzer unerreichbares Verzeichnis wechselt und sich dann in diesen Nutzer "verwandelt".

Besonderheiten bei bestimmten lokalen Dateisystemen

ext2 / ext3

Dieses Filesystem bietet einige besondere Flags, die mit dem Kommando chattr gesetzt werden koennen.

Bit Erklärung
A Die atime von Dateien oder Verzeichnissen mit diesem Flag wird bei Zugriff nicht veraendert. Hinweis: Das kann man auch mit der mount-Option "noatime" bei vielen Dateisystemen erreichen.
a An Dateien mit diesem Flag koennen Daten nur angefuegt, nicht jedoch beliebig geschrieben werden. Das ist z.B. fuer logfiles gut geeignet. Es ist jedoch zu beachten, dass Schreibzugriff auf solche Dateien ueber Netzwerkdateisysteme wie nfs nicht mehr moeglich ist. Netzwerkdateisysteme arbeiten i.d.R. idempotent und sind deshalb nicht in der Lage Daten an eine Datei anzufuegen. Das Anfuegen wuerde dann durch absolutes Schreiben hinter dem Dateiende simmuliert, was jedoch mit diesem Flag nicht mehr funktioniert.
D Auf Verzeichnisse mit diesem Flag wird synchron geschrieben. D.h.: Alle Schreibzugriffe werden direkt auf die Platte ausgefuehrt und nicht gepuffert.
d Dateien mit diesem Attribut werden bei Benutzung von dump nicht gesichert.
i Dieses "Immutable"-Flag kann nur von Benutzer mit der UID 0 (meistens nur root) veraendert werden. Ist es gesetzt, kann das Dateisystemobjekt nicht veraendert werden, auch nicht von root. Es steht root natuerlich frei, das Flag wieder zu entfernen :-) .
j Daten eines solchen Files werden durch das ext3-Journal des Filesystems vor Korruption gesichert. Es darf nur durch UID 0 veraendert werden.
s Ist dieses Flag gesetzt, werden die Daten des Files beim Loeschen vernichtet und nicht nur als "frei" markiert. Das ist fuer sensible Daten sinnvoll (z.B. fuer Dateien mit Passwoertern).
S Dateien mit diesem Flag werden synchron geschrieben. D.h. alle Schreiboperation werden vom Programm unter Umgehung des Write-Back-Caches direkt auf die Partition ausgefuehrt.
T (unbekannt, sorry :-( )
t Diese Option verhindert, dass 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. Dass ist nur bei Dateien noetig, auf die unter Umgehung des Filesystemtreibers zugegriffen werden muss (z.B. fuer /vmlinuz , wenn es durch lilo beim Bootvorgang von der Platte gelesen wird).
u Die "undelete"able-Option sorgt dafuer, dass eine Datei beim Löschen (also nach dem letzten unlink() ) nicht wirklich gelöscht wird. root kann die Datei dann bei Bedarf wiederherstellen.
X (unklar, wird angeblich für Kompression benutzt)
Z (unklar, wird angeblich für Kompression benutzt)

Diese Daten entstammen der man-Page zu chattr. Welche der Flag wirklich eine Wirkung haben, ist mir nicht bekannt.

XFS (High-Performance Filesystem von SGI)

XFS bietet auf Dateiebene folgende Erweiterungen:
  • Posix-ACLs zur Zugriffssteuerung fuer Inodes (also fuer alle Verzeichnisse Dateien und andere Dateisystemobjekte)
  • Erweiterte Attribute für Inodes. Erweiterte Attribute sind Datenblöcke, die mit einem Namen versehen zusätzlich zum primären Datenstrom einer Datei noch an dieser dranhängen.

Die Zugriffsrechte für das Lesen und Schreiben von erweiterten Attributen werden äquivalent zu den Zugriffsrechten auf den Inode allgemein ermittelt (Wer eine Datei lesen darf, darf auch die Attribute lesen, ...) .

Posix-ACLs sind immer positiv (Rechte können nur gewährt, nicht explizit aberkannt werden). Verzeichnisse enthalten eine zusätzliche ACL, die für alle in ihnen angelegte Dateisystemobjekte als Standard-ACL benutzt wird.

Netzwerkdateisysteme

Allgemeines zu Netzwerkdateisystemen

Der Mythos des x-Bits

Die exakte Trennung zwischen den Rechten

  • Ausführen eines Programmes und
  • Lesen der Datei, die das Programm enthält
sind in Netzwerkdateisystemen nicht durchsetzbar - auch wenn es (durch eine entsprechende Nachahmung auf Clientseite) vielleicht so scheint.

Beispiel: Ein supergeheimes Programm soll jeder ausführen dürfen aber keiner Lesen dürfen. Für den Fileserver ist das schlicht ein Wiederspruch. Für den Server macht es keinen Unterschied, ob eine Datei von einem Client geholt wird, um sie zu lesen oder um sie auszuführen. Selbst wenn der Client eine Hinweis der Art Ich will diese Datei wirklich nur ausführen und nicht lesen - versprochen! mitschickt - der Server kann sich nicht auf die Richtigkeit dieser Angabe verlassen.

Schlussfolgerung: Sicherungsmassnahmen, die auf dem x -Bit beruhen, sind in Netzwerkdateisystemen prinzipiell sinnlos.

Authentifizierung - Wo? Warum dort?

... am Client
Der Server eines Netzwerkdateisystemes muß irgendwie erkennen, wer gerade versucht, z.B. eine Datei von ihm abzurufen. Ginge das Nicht, wäre die Rechteverwaltung des Dateisystems sinnlos. Dazu muss sich Benutzer ausweisen - man nennt das Authentifikation. Bei klassischen lokalen Dateisystem ist das einfach - der Benutzer weist sich mit der UID des jeweiligen Prozesses aus. Unter der entsprechenden UID kann er schliesslich nur arbeiten, wenn er sich (z.B. mit einem Passwort) an dem entsprechenden Rechner angemeldet hat. Hier gilt natürlich wieder: root darf alles - schliesslich kann sich root in jeden Benutzer verwandeln.

Im Netzwerk ist die Authentifizierung ungleich schwieriger und (wenn sie sicher sein soll) kompliziert genug, um mehrere Doktorarbeiten locker auszufüllen. Die einfachste, jedoch extrem unsichere Methode ist die Authentifikation am Client - wie es z.B. bei NFS bis Version 3 in der Grundeinstellung gemacht wird. Dabei wird bei jeder Anfrage (eine Anfrage ist z.B. ein einzelner Lesezugriff auf eine Datei) an den Server die UID des Benutzers auf dem Client mitgeschickt. Der Server prüft dann, ob diese UID das Recht hat, einen solchen Lesezugriff auszuführen und reagiert entsprechend.

Das setzt allerdings vorraus, dass nur vertrauenswürdige Personen root-Rechte auf dem Client haben - sonst könnten sich ja unberechtigte Personen auf dem Client einfach in jeden Benutzer verwandeln (-> root darf alles ). Daraus folgt, dass die Daten in einem solchen Netzwerk nur so sicher sind, wie man die Clients absichert. Prinzipiell kann man aber einen Computer, den man nicht physisch kontrolliert (z.B. durch Einschliessen in den Serverraum), nicht absichern - es gibt ja schliesslich Knoppix und co., womit jeder zur root werden kann. Diese Form der Sicherheit ist zwar weit verbreitet, jedoch technisch vollkommen überholt.

... am Server
Eine sichere Authentifizierung muss am Server ansetzen. Da man Clients nicht absichern kann, muß man die root darf alles -Regel auf dem Client in Bezug auf Netzwerk-Filezugriffe umgehen. Dazu gibt es mehrere denkbare Ansätze:
  1. Die Verbindung zum Server wird in Form ein Sitzung vor dem ersten Dateizugriff aufgebaut - das SMB-Protokoll arbeitet z.B. so. Dazu wird das Dateisystem des Fileservers an einen bestimmten Pfad auf dem Client gemountet - man sollte jedoch nicht vergessen, es später wieder zu unmount en.
    Nachteil: Mehrere Benutzer können sich nicht mit unterschiedlichen Identitäten den selben Pfad teilen - einheitliche Verzeichnispfade sind also schwer bis unmöglich zu realisieren, wenn mehrere Leute an einem Client arbeiten.
  2. Bei jeder Anfrage an den Fileserver wird ein geheimes Datenpaket mitgeschickt (z.B. das Benutzerpasswort). Der Fileserver prüft anhand des Passwortes, ob der Benutzer der ist, der er zu sein vorgibt.
    Nachteile:
    • Wer das Passwort einmal abgehört hat, kann sich als der entsprechende Nutzer ausgeben - bis dieser sein Passwort ändert (was beim Durchschnittsbenutzer nicht oft passiert).
    • Das Passwort muss irgendwie im Kernel gespeichert werden - man will ja schliesslich wie gewohnt mittels Dateizugriffe auf seine Files zugreifen und nicht so etwas wie einen grafischen FTP-Client benutzen. Das macht die Sache komplizierter.
  3. Ticketbasierte Authentifikation. Dabei wird vor dem ersten Zugriff z.B. das Passwort benutzt, um von einem speziellen Sicherheitsserver ein Datenpaket (ein Ticket, unter AFS ein Token) zu bekommen, dass man dem Fileserver bei jedem Zugriff vorlegt (Es ist in Wirklichkeit noch etwas kompliziert, aber um das Prinzip zu verstehen, reicht diese Erklärung.). Dieses Datenpaket ist nur eine begrenzte Zeit (z.B. 10 Stunden) gültig. Nach Ablauf der Zeit, glaubt der Fileserver dem Benutzer nicht mehr, dass er wirklich der ist, der er zu sein vorgibt - man muss sich vom Sicherheitsserver ein neues Ticket holen.
    Nachteile:
    • Kryptografische Routinen sind aufwendig (Ticketbasierte Authentifikation beruht immer auf Kryptografie) und müssen sauber programmiert sein, damit sie sicher sind.
    • Das Ticket (oder der Token) muss im Kernel gespeichert werden. Dazu sind Kernelerweiterungen (z.B. in Form von Kernelmodulen) und spezielle Tools nötig, um die Tickets/Tokens im Kernel zu verwalten.
    • Der Sicherheitsserver bedeutet zusätzlichen administrativen Aufwand. Kerberos (das Original kommt vom MIT, es gibt aber noch weitere ähnliche Lösungen) ist ein solches System - das dazu auch noch kostenlos ist.
    • Benutzer sind es nicht gewöhnt, dass die Authentifikation zeitlich beschränkt ist.

NFS2 und NFS3

NFS, ein Netzwerkdateisystem, ist nicht 100%-ig kompatibel zu herkömlichen Unix-Filesystemen, obwohl eine möglichst hohe Kompatibilität Designziel war.

Einige Inkompatibilitäten wurden aus Sicherheitsgründen zusätzlich eingebaut, wenn auch der Sicherheitsgewinn zweifelhaft ist. Die bekannteste ist der root_squash . Diese (serverseitig einzustellende) Option ändert Zugriffe, die unter der UID 0 erfolgen und führt sie unter einer niedrig privilegierten UID (zumeist die von "nobody") aus. Damit wird die root darf alles -Regel teilweise gebrochen (Root kann sich natürlich vorher auf dem Client in andere Benutzer verwandeln, um dem root_squash ein Schnippchen zu schlagen).

Hinweise:

  • Alle Dateisystemobjekte in einem per NFS-gemounteten Verzeichnisbaum werden vom Client interpretiert.
    • Es gibt deshalb keine Möglichkeit, ueber eine Named Pipe Daten zwischen mehreren Rechnern auszutauschen oder ueber Device-Files im NFS-Mount auf Geraete des Servers zuzugreifen.
    • Device-Files, Sockets, und Pipes sind jedoch prinzipiell unter NFS erlaubt. NFS-Verzeichnisse werden jedoch i.d.R. mit der Option nodev gemoutet, was den Zugriff auf darauf gespeicherte Device-Files aus Sicherheitsgruenden unterbindet.
  • Es ist möglich, einen Verzeichnisbaum per NFS zu mounten, bei dem die "root darf alles"-Regel gilt. Dazu ist der Parameter "no_root_squash" fuer den Export auf dem Server zu aktivieren.
  • Von NFS existieren verschiedene Versionen:
    1. (gab es nie)
    2. Die erste offiziell von Sun herrausgebrachte Version. NFS V2 ist der kleinste gemeinsame Nenner und funktioniert im Zweifelsfall praktisch immer.
    3. NFS V3 ist performanter als NFS V2.
    4. Zum jetzigen Zeitpunkt wird an NFS V4 für Linux noch kräftig entwickelt. Vor allem sicherheitstechnisch bietet es Vorteile gegenueber NFS 2 und 3. Inwiefern die in diesem Abschnitt gemachten Aussagen zu NFS auch auf V4 zutreffen kann ich mangels Erfahrung nicht sagen.
  • NFS V2 und V3 sind für zu sichernde Daten nicht zu empfehlen, da bereits ein mit einer Boot-CD bewaffneter Angreifer an einem Client-Computer das Sicherheitsmodell von NFS aushebeln kann.

AFS

AFS, ebenfalls ein Netzwerkdateisystem, führt jedoch im Gegensatz zu NFS eine zusätzliche Virtualisierungsebene fuer den Zugriff auf Daten ein. Für weitere Informationen sollte man sich auf OpenAFS.Org umsehen. Das in deutsch dokumentierte Projekt InstantAFS erleichtert den Einstieg. AFS speichert für alle Dateien und Verzeichnisse die Permission-Bits von Unix, obwohl sie vom AFS-Client nicht ausgewertet werden (mit Ausnahme des x -Rechts, das Dateien als ausführbar markiert).

Hinweise:

  • Manche Programme analysieren die Permissions an Dateien/Verzeichnissen und üben sich in Selbstbeschränkung.
    Beispiel:
    • konqueror : Wenn man mit Konqueror (KDE 3.4) versucht, Dateien zu löschen, auf die man laut Permissions/Owner keinen Zugriff hat, kann man diese nicht löschen.
  • AFS verwaltet Rechte nicht pro Datei sondern immer für ganze Verzeichnisse. Wenn man verschiedene Rechte für bestimmte Dateien in einen einzigen Verzeichnis setzen möchte, muss man diese in andere Verzeichnisse verschieben, dort die Rechte entsprechend setzen und Links auf die Dateien in den neuen Verzeichnissen anlegen.
  • Root zu sein bedeutet im AFS nichts. Benutzer werden nicht durch ihre UID sondern durch die AFSID identifiziert. Die AFSID wird von einem Programm (i.d.R. klog oder aklog) im Kernel des Client-Computers zusammen mit einem Schlüssel - genannt token - abgelegt. Dieser Schlüssel wird bei jedem Zugriff auf das AFS (also z.B. bei jedem einzelnen Schreiben eines Datenblocks in eine Datei) an den entsprechenden Server zur Authentifikation geschickt. Der Schlüssel ist nur eine begrenzte Zeit gueltig und muss danach (i.d.R. durch erneutes Anmelden mit Password, am Client-Computer) neu erstellt werden.
  • Unter AFS gibt es zellenweite Superuser. Die Mitglieder der Gruppe system:administrators dürfen auf alle Dateien/Verzeichnisse einer AFS-Zelle beliebig zugreifen. Allerdings gilt auch für diese Nutzer, dass alle Rechte zeitlich begrenzt sind.
  • Neu angelegte Verzeichnisse übernehmen die ACLs des jeweils übergeordneten Verzeichnisses.
  • AFS beherrscht Inode-Abstraktion, jedoch müssen alle harten Links auf einen Inode im selben Verzeichnis liegen. Der Grund dafür ist, dass sonst die Rechte beim Zugriff auf den Inode durch die an Verzeichnisse gebundene Rechteverwaltung nicht eindeutig wären.

Dateisystemzugriffe

Authentifikation und Autorisation der Benutzer erfolgt unter AFS ausschliesslich beim Server, was es sehr sicher macht. Die Kompatibilitaet zu klassischen Unix-Dateisystemen ist jedoch stark eingeschränkt.

AFS benutzt sogenannte ACLs (Access Control Lists), um den Zugriff auf Dateien und Verzeichnisse zu steuern. Eine ACL besteht jeweils aus einer Liste von Zuordnungen der Form (Benutzer oder Gruppe -> Rechte). Maximal 20 derartige Zuordnungen koennen in einer ACL stehen. Zu jedem Verzeichnis existieren genau 2 ACLs. Die positive ACL definiert die Rechte auf ein Verzeichnis. Die negative ACL definiert, wem welche Rechte nach Auswertung der positiven ACL wieder aberkannt werden.

Folgende Rechte existieren unter AFS:

Symbol Erklärung
r Lesen von Dateien eines Verzeichnisses, auslesen von Metainformationen ( stat() ), auslesen von Linkzielen ( readlink() )
l Dieses Recht erlaubt es, in das entsprechende Verzeichnis zu wechseln und den Inhalt zu ermitteln ( readdir() ). Wer dieses Recht nicht hat, darf gar nichts in diesem Verzeichnis
w Dieses Bit symbolisiert die Moeglichkeit, in bereits angelegte Dateien eines Verzeichnisses zu schreiben.
i Das Anlegen neuer Dateien und Verzeichnisse ist mit diesem Recht verbunden. Ausserdem ist dieses Recht nötig, um Dateien umzubenennen oder mit ln zusätzliche harte Links auf sie anlegen zu können. Das i -Recht gewährt ausserdem implizit r sowie w -Permissions für Dateien, deren Owner man ist.
d Löschen von Dateien oder Unterverzeichnissen in einem Verzeichnis
k Benutzen von Dateisperren ( flock() ) fuer Dateien eines Verzeichnisses. Diese Sperren gelten dann für die gesammte AFS-Zelle.
a Ändern der ACLs eines Verzeichnisses
A, B, C, D, E, F, G, H Diese Rechte koennen von eigenen AFS-Server-Implementationen benutzt werden und haben im Standard-AFS keine Bedeutung.

Hinweise:

  • Die ACLs (und damit die Rechte) eines Verzeichnisses darf jeder ändern, der in der ACL des Verzeichnisses das "a"-Recht zugestanden bekommt.
  • Die Gruppe "system:administrators" hat implizit das Recht, alle Rechte zu setzen.
  • Unter www.openafs.org? hat der Besitzer des Grundverzeichnisses eines Volumes implizit für alle Verzeichnisse des Volumes Administrationsrechte.

Benutzergruppen

Unter AFS kann jeder authentifizierte Nutzer mit dem pts-Kommando eigene Gruppen anlegen, bearbeiten und löschen. Diese Gruppen kann man dann in ACLs benutzen.

Hinweise:

  • Jeder authentifizierte Benutzer darf Benutzergruppen anlegen - die Namen dieser Gruppen müssen sich jedoch aus dem Namen des Nutzers, einem : -Zeichen und einer beliebigen Zeichenfolge zusammensetzen. Wahlfreie Bezeichnungen für Gruppen dürfen nur Mitglieder von system:administrators vergeben.
  • Es existiert eine durch Superuser veränderliche Maximalanzahl von selbsterstellten Gruppen ( Group Quota ), die per default 20 ist.
  • Wenn die eigene Mitgliedschaft in einer Gruppe umdefiniert wurde (z.B. wenn man Mitglied in einer Gruppe wird), registriert der AFS-Server das u.U. erst, wenn man sich erneut im AFS authentifiziert. Das liegt an einem Caching-Mechanismus auf Serverseite.
  • Die Liste der Gruppen und Benutzer dürfen nur Superuser anzeigen lassen ( pts listentries )

Direkter Zugriff auf AFS-Serverprozesse

Mit den Kommandos vos, bos und einigen anderen kann man AFS-Server direkt ansprechen und auf diesen bestimmte Aktionen ausfuehren. Einige Kommandos darf dabei jeder ausfuehren (z.B. vos listvol), andere sind privilegierten Nutzern vorbehalten (z.B. vos release).

Diese Kommandos benutzen den im Kernel gespeicherten Schluessel, um sich gegenüber einem AFS-Server als ein bestimmter Nutzer zu authentifizieren. Einige Kommandos erlauben auch, dazu den AFS-Zellen-Schlüssel eines AFS-Servers zu benutzen. Dieser Zellenschlüssel sollte nur auf AFS-Servern liegen. Er ermöglicht die totale Kontrolle über eine AFS-Zelle.

Privilegierter Nutzer kann man auf jedem Server jeweils sein oder nicht sein. Jeder AFS-Server (genauer: der bosserver-Prozess) führt eine Liste über solche Nutzer. Mittels des bos-Kommandos kann man diese Listen bearbeiten. In solchen Benutzerlisten können keine Gruppen verwendet werden. Es ist zu beachten, dass derartig privilegierte Nutzer mit geringem Aufwand vollen Zugriff auf die AFS-Zelle (sprich: Rechte der "systen:administrators"-Superuser) erhalten. Es sollten also niemals (nocheinmal: %RED$ niemals ) normale Nutzer in einer dieser Listen stehen.

Anhang

Was ist nötig, damit...

... eine Datei ausgeführt werden kann?

Eine Datei kann man genau dann ausführen, wenn folgende Bedingungen erfüllt sind:
  1. Die Datei muss erreichbar sein.
  2. Die Datei muss ausführbar sein. Man muss das Recht x inne haben.
  3. Die Datei muss auf einem Filesystem liegen, das mit der Mountoption "exec" gemountet ist.

Zu 3.: Der mount-Befehl setzt u.U. aus Sicherheitsgründen ungewöhnliche Standardoptionen für gemountete Filesysteme. Diese schränken dann bestimmte Unix-Funktionen ein. Das root-Filesystem ist davon i.d.R. ausgenommen. Wenn man sicher ist, Dateien auf einer Partition starten zu wollen, muss man die Mountoption "exec" angeben. Das kann z.B. als Eintrag in der Datei /etc/fstab geschehen.

/dev/hda2       /               xfs     defaults,rw,exec               0       1

Soll die Datei mit anderen Nutzerrechten (SetUID? oder SetGID?) ausgeführt werden, so sind zusätzlich folgende Punkte zu beachten:

  1. Fuer die Datei muessen die entsprechenden Set(U|G)-Bits gesetzt sein.
  2. Das Filesystem, auf dem die Datei liegt, muss mit der Option "suid" gemountet sein. Diese Mountoption ist per default abgeschaltet (zumindest unter Linux).

[Zurück zum Start]

Aktuelle Wiki-Seite: Linux > UnixPermissions

[Zurück zum Start]