Allgemein

1.105.1 – Kernel und Kernelmodule

Schreibe einen Kommentar

1.105.1 – Verwalten/Abfragen von Kernel und Kernelmodulen zur Laufzeit
Prüfungskandidaten sollten in der Lage sein, Kernel und ladbare Kernelmodule zu verwalten und/oder abzufragen. Dieses Lernziel beinhaltet die Verwendung von Kommandozeilen-Utilites, um Informationen über den gerade laufenden Kernel und die Kernelmodule zu erhalten. Ebenfalls enthalten ist das manuelle Laden und Entladen von Modulen nach Bedarf. Dies beinhaltet auch die Bestimmung, wann Module entladen werden können und welche Parameter ein Modul akzeptiert. Prüfungskandidaten sollten in der Lage sein, das System so zu konfigurieren, daß Module auch durch andere als ihre Dateinamen geladen werden können.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* /lib/modules/kernel-version/modules.dep
* /etc/modules.conf & /etc/conf.modules
* depmod
* insmod
* lsmod
* rmmod
* modinfo
* modprobe
* uname
Kernelmodule
Der Linux-Kernel war anfangs (in der Version 1.x.x) ein rein monolithisches Gebilde. Das hatte zur Folge, daß jede Hardware-Unterstützung fest in den Kernel eingebunden werden musste. So entstanden entweder sogenannte Allround-Kernel, die riesengroß waren und Unterstützung für die abenteuerlichste Hardware zur Verügung stellten, oder es musste für jede neue Hardware, die in einen Rechner eingebaut wurde, ein neuer Kernel erstellt werden. Beides war keine praxistaugliche Lösung.

Aus diesem Grund wurde der Kernel modularisiert. Das heißt, daß bestimmte Teile des Kernels nicht mehr beim Compilieren fest eingebunden werden müssen, sondern später, während der Laufzeit, ge- und auf Wunsch auch wieder entladen werden können. Diese Fähigkeit ermöglicht es, daß Gerätetreiber eben nicht immer fest eingebunden werden müssen, sondern je nach Bedarf nachgeladen werden können. Distributoren können so schlanke Kernel ausliefern, die trotzdem alle Fähigkeiten von Linux unterstützen, weil die jeweiligen Fähigkeiten bei Bedarf geladen werden können. Die Teile des compilierten Kernels, die nicht fest eingebunden sind, sondern ge- und entladen werden können, werden Kernelmodule genannt.

Die Kernelmodule des Linux-Kernels werden im Dateisystem unter /lib/modules/Kernelversion abgespeichert, wobei Kernelversion für die Versionsnummer des Kernels steht, für den die Module passen. Die Module bestehen aus Objektdateien (Endung .o), die in diesem Verzeichnis in diverse Unterverzeichnisse sortiert sind.

Kernelmodule sind Teile des Kernels, zwar ausgelagert, aber doch Teile des Ganzen. Wenn solche Module ein- und ausgehängt werden, so spielen bestimmte Abhängigkeiten (dependencies) eine Rolle. Beispielsweise kann der Kernel nichts mit einem Modul anfangen, das ihm die Fähigkeit verleihen soll, mit SCSI-CDROMs umzugehen, wenn er gar nicht weiß, was SCSI ist. Das Modul für die SCSI-CDROMs ist also abhängig vom generellen Modul für SCSI. Diese Abhängigkeiten müssen den Programmen bekannt sein, die die Module laden und entladen. Aus diesem Grund existiert das Programm depmod, das die Abhängigkeiten aller Module untersucht und die Ergebnisse in die Datei /lib/modules/Kernelversion/modules.dep schreibt. In dieser Datei stehen dann – in klar lesbarer Form – die entsprechenden Abhängigkeiten jedes einzelnen Moduls. Jedesmal, wenn neue Module ins Modulverzeichnis kopiert werden, muß anschließend dieses Programm aufgerufen werden.

Programme zum Umgang mit den Modulen
Es gibt jetzt eine Reihe von Befehlen, die es ermöglichen mit Kernelmodulen umzugehen. Diese Befehle werden jetzt der Reihe nach kurz beschrieben.

Auflistung der geladenen Module
Um herauszufinden, welche Module bereits geladen sind, existiert der Befehl lsmod. Er zeigt alle geladenen Module im Format Name, Größe, Wie-oft-gebraucht und Liste der Module, die das Modul benötigen. Dieser Befehl dient also hauptsächlich dazu, zu überprüfen, ob ein bestimmtes Modul geladen ist oder nicht. lsmod wird ohne Parameter aufgerufen.

Laden von einzelnen Modulen
Um ein einzelnes Modul zu laden, kann der Befehl insmod verwendet werden. Als Parameter erwartet insmod den Namen des zu ladenden Moduls. Der Name wird ohne die Endung .o angegeben. Auch Pfade werden keine benötigt. Das Programm weiß ja selbst, in welchem Verzeichnis die ladbaren Module des aktuellen Kernels zu finden sind. Um also beispielsweise das Modul /lib/modules/Kernelversion/kernel/drivers/usb/printer.o zu laden genügt die Angabe

insmod printer

Anhand der aktuellen Kernelversionsnummer ermittelt insmod das notwendige Basisverzeichnis für die Module und kann dort über die Datei modules.dep den genauen Pfad zum gewünschten Modul ermitteln.

Wenn ein Modul selbst noch Parameter erwartet, z.B. die I/O-Adresse einer ISA-Netzwerkkarte, so werden sie nach dem Modulnamen angegeben. Diese Parameter haben immer die Form

Symbolname=Wert

Für die ISA-Netzwerkkarte könnte das z.B. der Befehl

insmod ne io=0x300 irq=5

sein. Damit wird das Modul ne geladen (ein Modul für eine NE2000 Netzwerkkarte) und bekommt als Parameter die Werte für IO-Adresse und IRQ übergeben.

Das Programm insmod läd nur das angegebene Modul. Wenn dieses Modul andere Module benötigt, so werden sie nicht mitgeladen.

Laden eines Moduls mit allen nötigen Zusatzmodulen
Damit man auch Module laden kann, und automatisch alle notwendigen Zusatzmodule mitgeladen werden, existiert der Befehl modprobe. Er hat heute den Befehl insmod völlig verdrängt, denn er ist wesentlich intelligenter. Die Anwendung entspricht der von insmod. Als Parameter wird das zu ladenden Modul, wiederum ohne Pfad und ohne der Endung .o angegeben. Auch eventuell notwendige Parameter werden wie bei insmod angegeben.

Im Gegensatz zu insmod überprüft modprobe die Abhängigkeiten der Module untereinander (über die Informationen aus modules.dep und läd alle Module, die das angegebene Modul benötigt, um richtig zu funktionieren. Ein Beispiel:

Wenn wir das Modul für ein am Parallelport angeschlossenes Zip-Laufwerk (ppa) laden wollen, so benötigt dieses Modul, das generellen Zugriff auf Parallelports ermöglicht (parport). es reicht zu schreiben

modprobe ppa

und modprobe erkennt, daß eine nicht erfüllte Abhängigkeit vorliegt, läd zuerst das Modul parport und erst danach das Modul ppa.

Anstatt Parameter für bestimmte Module direkt anzugeben, unterstützt modprobe (nicht insmod) eine Datei, die die notwendigen Modulparameter enthält. Diese Datei heißt entweder /etc/conf.modules (alt) oder modules.conf (aktuell) und wird weiter unten noch genauer beschrieben.

Um genau zu sein, benutzt modprobe das Programm insmod um die notwendigen Module zu laden. modprobe ist also eine Art High-Level Programm zum Laden der Module oder ein Frontend für insmod.

Entfernen von geladenen Modulen
Wenn ein Modul nicht mehr benötigt wird, so kann es mit dem Befehl rmmod wieder aus dem Kernel entfernt werden. rmmod kann keine Module entfernen, die gerade in Gebrauch sind oder die von anderen geladenen Modulen benötigt werden. Allerdings ist es möglich, mit dem Kommandozeilenparameter -r dafür zu sorgen, daß rmmod so funktioniert, wie ein umgekehrtes modprobe, also nicht nur das angegebene Modul entfernt, sondern alle, die nur deshalb geladen sind, damit das zu entfernende Modul funktioniert.

Auch dieses Programm erwartet den Namen des zu entfernenden Moduls ohne Endung und Pfad.

Auch das Programm modprobe kann verwendet werden, um Module wieder zu entfernen. Mit dem Parameter -r werden Module entfernt, die auf der Kommandozeile angegeben wurden.

Modulparameter erkennen und einstellen
Module sind häufig Gerätetreiber für bestimmte Hardware. In vielen Fällen ist es notwendig, für die Ansteuerung der Hardware bestimmte Parameter wie IO-Port, IRQ usw. anzugeben, wenn ein Modul geladen werden soll. Wie oben gesehen, werden Parameter für Module immer in der Form

Symbolname=Wert

angegeben. Dazu muß aber klar sein, welche Symbolnamen das jeweilige Modul kennt, also welche Parameter es versteht. Um das herauszufinden gibt es das Programm modinfo. Dieses Programm gibt Informationen über ein Modul aus, unter anderem welche Parameter angegeben werden können. Auch modinfo arbeitet mit den Modulnamen ohne Endung und Pfad. Über Kommandozeilenparameter kann angegeben werden, welche Informationen ausgegeben werden sollen, ohne solche Schalter werden die Informationen über

* Dateiname und Pfad der Moduldatei (-n)
* Beschreibung (-d)
* Author (-a)
* Lizenz (-l)
* Parameter (-p)

ausgegeben. Um z.B herauszufinden, welche Parameter das Modul 3c509 (ein Gerätetreiber für eine 3Com Netzwerkkarte) benötigt, können wir schreiben

modinfo -p 3c509

Die entsprechende Ausgabe des Programms wäre:

debug int, description „EtherLink III debug level (0-6)“
irq int array (min = 1, max = 8), description „EtherLink III
IRQ number(s) (assigned)“
xcvr int array (min = 1, max = 8), description „EtherLink III
tranceiver(s) (0=internal, 1=external)“
max_interrupt_work int, description „EtherLink III maximum events
handled per interrupt“
nopnp int, description „EtherLink III disable ISA PnP support (0-1)“

Daraus können wir entnehmen, daß dieses Modul die Parameter debug, irq, xcvr, max_interrupt_work und nopnp versteht. Alle diese Parameter erwarten ganzzahlige (int) Werte. Wenn hier die Angabe array steht, so ist gemeint, daß wenn mehrere gleichartige Karten existieren, die alle dieses Modul benötigen, dann an Stelle der normalen Angabe einer Zahl, eine durch Komma getrennte Liste von Zahlen verwendet wird. Bei drei solcher Netzwerkkarten hieße der Parameter, der den IRQ einstellt also irq=3,5,7. Die erste Karte benutzt IRQ3, die zweite 5 und die dritte 7.

Die Datei /etc/modules.conf
Um den Kernelmodulen ihre Parameter an einer festen Stelle angeben zu können, wurde modprobe so programmiert, daß es die Datei /etc/modules.conf (oder /etc/conf.modules) abarbeitet und dort entsprechende Parameter für die Module entnimmt.

Die Datei kann auch noch mehr, als nur Parameter für Module zur Verfügung stellen. Insbesondere können damit

* Parameter für Module festgelegt werden,
* Aliasnamen für Module vergeben werden,
* Module angegeben werden, die vor oder nach dem eigentlichen Modul geladen werden sollen,
* Module, die vor oder nach dem Laden des eigentlichen Moduls entfernt werden sollen

Die Datei hat ein einfaches Format. Jede Zeile, die nicht mit einem Kommentarzeichen (#) beginnt oder leer ist, wird als Anweisung interpretiert. Um einem Modul bestimmte Parameter zu setzen, wird der Befehl options benutzt. Er hat die folgende Syntax:

options Modulname Optionen

Ein Eintrag für unsere NE2000 Netzwerkkarte, könnte also so aussehen:

options ne io=0x320 irq=7

Jedesmal, wenn jetzt mit modprobe das Modul ne geladen wird, werden automatisch diese Optionen mitgeladen.

Um ein Modul auch mit anderem Namen anzusprechen, können wir Aliasnamen vergeben. Das bedeutet, daß mit modprobe auch Module geladen werden, die es gar nicht gibt, sondern die nur Aliasnamen sind. Die Syntax ist

alias Aliasname Modulname

Diese Methode wird gerne benutzt um bestimmte Hardware an einen Begriff zu binden, der mehr aussagt und allgemeiner handhabbar ist als der Modulname. So kann z.B. der Aliasname eth0 an die tatsächliche Netzwerkkarte gebunden werden. Der Eintrag

alias eth0 ne
alias eth1 off

options ne io=0x320 irq=7

würde es also ermöglichen, daß wir (oder ein init-script) den Befehl

modprobe eth0

eingeben und so automatisch das Modul ne mit den angegebenen Parametern geladen wird. Versucht aber jemand mit modprobe das Modul eth1 zu laden, dann weigert sich modprobe irgendein Modul zu laden, da der Wert des Aliases off ist.

Mit pre-install können Befehle angegeben werden, die vor dem Laden des Moduls ausgeführt werden sollen. Diese Befehle können (müssen aber nicht) andere Module laden. Die Syntax lautet:

pre-install Modul Kommando

Bevor das Modul geladen wird, wird erst das Kommando ausgeführt. Analog dazu gibt es die Befehle

post-install Modul Kommando
pre-remove Modul Kommando
post-remove Modul Kommando

die entsprechend nach dem Laden, vor dem Entfernen und nach dem Entfernen bestimmter Module bestimmte Kommandos ausführen. Alle vier Kommandos können auch auf Aliasnamen angewandt werden.
Der Befehl uname
Der Befehl uname gibt Informationen über den Kernel und das System aus. Um z.B. die aktuelle Kernelversion zu erfragen, genügt ein Aufruf von

uname -r

Das ist z.B. die Methode, mit der erfragt werden kann, in welchem Verzeichnis die Module des Kernels liegen. Es ist tatsächlich möglich zu schreiben

cd /lib/modules/`uname -r`/kernel

Durch die Kommandosubstitution wird das Konstrukt `uname -r` durch die Ausgabe des Befehls ersetzt und die entspricht genau dem, was als Verzeichnisnamen vorliegt.

Alle Informationen können mit uname -a ausgegeben werden, die restlichen Parameter entnehmen Sie der Handbuchseite.

Allgemein

1.105 – Kernel

Schreibe einen Kommentar

Dieses Thema enthält zwei Kapitel, die sich um den Umgang mit dem Kernel selbst drehen. Dabei ist der Umgang mit Kernelmodulen während der Laufzeit und das Erstellen eines eigenen Kernels das Lernziel. Weitergehende Techniken, wie etwa das Patchen eines Kernels wird erst für LPIC Level 2 interessant.
# Verwalten/Abfragen von Kernel und Kernelmodulen zur Laufzeit
# Konfiguration, Erstellung und Installation eines angepaßten Kernels und seiner Module

Allgemein

1.104.7 – Symbolische Links

Schreibe einen Kommentar

1.104.7 – Erzeugen und Ändern von harten und symbolischen Links
Prüfungskandidaten sollten in der Lage sein, harte und symbolische Links auf eine Datei zu verwalten. Dieses Lernziel beinhaltet das Erzeugen und Bestimmen von Links, das Kopieren von Dateien über Links und das Verwenden von verknüpften Dateien zur Unterstützung von Tätigkeiten der Systemadministration.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* ln
Links sind eine Spezialität von Unix-Dateisystemen, die gerne und häufig verwendet werden. Der Umgang mit ihnen ist eine wichtige und manchmal etwas verkopfte Angelegenheit, die ein Systemverwalter sicher beherrschen muß.

Unix und Linux unterscheiden zwischen Hardlinks (direkte Links) und Symlinks (symbolische Links). Die Eigenschaften dieser beiden Typen von Links sowie die Techniken, um sie anzulegen bzw. mit ihnen umzugehen sind Inhalt dieses Kapitels.

Hardlinks
In einem Unix-Dateisystem ist ein Dateiname nur ein Verzeichniseintrag, der in einem Verzeichnis gespeichert ist. Neben diesem Namen ist immer auch ein Verweis auf die Inode gespeichert, die dann die eigentlichen Eigenschaften (Eigentümer, Gruppenmitgliedschaft, Zugriffsrechte, usw.) der Datei und ihre physikalischen Speicheradressen auf der Platte enthält. Dieses Prinzip wurde auf den Seiten über Inodes und über das EXT2 Dateisystem bereits umfassend dargestellt.

Ein Hardlink ist nichts anderes, als ein neuer Verzeichniseintrag auf eine schon bestehende Inode. Also genau genommen ein zweiter Dateiname für eine Datei. Weil die Zugriffsrechte, Eigentümer usw. ja in der Inode stehen, haben alle Hardlinks einer Datei die selben solchen Attribute.

Wenn ein oder mehrere Hardlinks auf eine Datei zeigen, so ist nicht mehr zu unterscheiden, welcher davon das Original und welche die Links sind. Es handelt sich ja einfach nur um Namenseinträge, die auf die selbe Inode zeigen. Das heißt auch, daß Hardlinks immer noch gültig sind, wenn die Datei, auf die sie zeigen gelöscht wurde. Es wurde ja eben nicht die Datei gelöscht, sondern nur einer ihrer Namen. Solange noch weitere Namen existieren, wird die Datei nicht physikalisch gelöscht.

Die Ausgabe des ls -l Kommandos zeigt für jede Datei gleich nach dem Zugriffsmodus die Anzahl der Hardlinks (also der Namenseinträge), die diese Datei besitzt.

-rw-r–r– 1 root root 4326 Apr 8 15:02 datei1.txt
-rw-r–r– 5 root root 1578 Apr 8 15:02 datei2.txt

Auch hier wird nicht zwischen Original und Link unterschieden (geht ja eben auch gar nicht) so daß eine Datei mit nur einem Namen hier eine 1 anzeigt. Die zweite Datei des obigen Beispiels hat also 5 Namen, das könnte bedeuten, daß die Datei erstellt wurde und anschließend vier Hardlinks auf sie erstellt wurden. Insgesamt existieren also 5 Namenseinträge für diese Datei.

Da die Hardlinks sozusagen innerhalb der Mechanismen eines Dateisystems arbeiten indem sie eigentlich nur Verweise auf schon bestehende Inodes sind, arbeiten diese Links nur innerhalb der Grenzen eines Dateisystems also einer Partition. Es ist also nicht möglich, Hardlinks auf einer zweiten Partition zu erstellen, die auf eine Datei zeigen, die auf der ersten Partition liegt!

Eine weitere Einschränkung von Hardlinks ist, daß es nicht möglich ist, Hardlinks auf Verzeichnisse zu legen. Es existiert zwar die Option -d (oder -F oder –directory) des Befehls ln, die die Fähigkeit erlauben soll, auf allen Linux-Dateisystemen ist dieses Feature aber verboten.
Symbolische Links
Die genannten Einschränkungen der Hardlinks (keine Links auf Verzeichnisse/ keine Links über die Dateisystemgrenze hinaus) können mit sogenannten symbolischen Links umgangen werden. Symbolische Links arbeiten nicht auf der Dateisystemebene, sondern sind einfach Dateien, die nichts anderes enthalten, als den Pfad zu der Datei (oder dem Verzeichnis), auf die sie zeigen. Damit sie als Links zu erkennen sind, haben sie einen eigenen Dateityp (l), der es dem Betriebssystem klar macht, daß es sich hier um einen Link und nicht um eine reguläre Datei handelt.

Das ls -l Kommando zeigt einen symbolischen Link also als solchen an:

-rw-r–r– 1 root root 276295 Apr 21 19:46 Datei1
lrwxrwxrwx 1 root root 6 Apr 21 19:46 Datei2 -> Datei1

Sowohl an der Angabe des Dateityps (l, als auch am Dateinamen, dem ein Pfeilsymbol und das Ziel des Links folgt, ist ersichtlich, daß es sich hier um einen symbolischen Link handelt. Genauso ist ersichtlich, worauf der Link zeigt. Beim Hardlink konnten wir Original und Link nicht unterscheiden, beim symbolischen Link sind sie eindeutig unterscheidbar.

Weil symbolische Links nicht auf der Ebene der Dateisysteme selbst arbeiten reagieren sie aber auch in anderen Beziehungen völlig anders, als die Hardlinks:

* Wenn die Datei (oder das Verzeichnis), auf die ein symbolischer Link zeigt nicht mehr existiert (z.B. gelöscht wurde), dann zeigt der symbolische Link „ins Leere“, der Link existiert zwar weiter, er funktioniert aber nicht mehr.
* Wird ein symbolischer Link mit einer relativen Pfadangabe erstellt und anschließend in ein anderes Verzeichnis kopiert, dann wird er womöglich nicht mehr weiter funktionieren, weil vom neuen Verzeichnis aus dieser Pfad nicht existiert.

Andererseits sind die symbolischen Links nicht eingeschränkt, was die Grenzen eines Dateisystems angeht oder die Verwendung für Verzeichnisse.
Das Programm ln
Um Links anzulegen, existiert das Programm ln. Die Aufrufform ist einfach,

ln [-s] Datei [Link]

Wird das Programm ln ohne den Parameter -s oder –symbolic aufgerufen, so wird ein Hardlink erstellt, mit einem dieser beiden Optionsschaltern wird ein symbolischer Link erstellt.

Wenn ein Hardlink erstellt wird, so muß die Datei, auf die der Link verweist existieren, wenn ein symbolischer Link erstellt wird, so gilt das nicht.

Wird beim Aufruf von ln der Linkname weggelassen, so wird ein Link mit gleichem Namen wie die Datei im aktuellen Verzeichnis erzeugt. Das setzt aber natürlich voraus, daß die Datei nicht im aktuellen Verzeichnis liegt.

Werden mehr als zwei Dateinamen angegeben (Datei und Link), so muß der letzte Parameter ein Verzeichnisname sein. In diesem Verzeichnis werden dann Links auf all die Dateien angelegt, die vor diesem letzten Parameter angegeben wurden.

Normalerweise überschreibt das Programm ln keine Dateien, wenn ein Link angelegt werden soll, dessen Namen schon existiert. ln bietet aber eine Fülle von Optionen, die diese Eigenschaft ändert, inclusive der Frage der automatischen Umbenennung von überschriebenen Dateien.

Identifikation von Hardlinks
Wie oben schon erwähnt, gibt es keine Möglichkeit, zwischen Hardlink und Original zu unterscheiden, weil es ja kein Original gibt, sondern nur mehrere Namen, die alle auf die gleiche Inode verweisen. Wenn wir nun herausfinden wollen, welche Dateinamen alle die selbe Inode verwenden, gibt es da durchaus eine Möglichkeit:

Zunächst einmal müssen wir herausbekommen, welche Inode von unserer Datei überhaupt belegt wird. Das ls-Kommando bietet uns mit der Option -i die Möglichkeit, das zu erfahren. Ein ls -i gibt uns zu den Dateinamen die verwendeten Inode-Nummern mit aus.

Dann können wir mit dem Programm find nach allen Dateien suchen, die diese Inode-Nummer benutzen. Allerdings sollten wir das ausschließlich innerhalb der Partition tun, auf der die Datei liegt, die wir untersuchen. Denn zufälligerweise kann ja eine ganz andere Datei auf einem ganz anderen Dateisystem (also auf einer anderen Partition) die selbe Inode-Nummer benutzen.

Spielen wir es einmal durch: Wir befinden uns im Verzeichnis /usr/local/data und das ls -l Kommando zeigt uns eine Datei mit Namen BEISPIEL.DAT folgendermaßen an:

-rw-r–r– 5 root root 1895 Apr 8 15:02 BEISPIEL.DAT

Aus der Angabe direkt nach dem Zugriffsmodus entnehmen wir, daß es insgesamt fünf Dateinamen gibt, die auf ein und dieselbe Inode verweisen. Also neben dieser Datei noch vier weitere. Zunächst müssen wir wissen, welche Inode diese Datei überhaupt benutzt. Dazu geben wir den Befehl

ls -i BEISPIEL.DAT

ein und bekommen die folgende Ausgabe:

92550 BEISPIEL.DAT

Die benutzte Inode ist also die Inode Nummer 92550. Jetzt müssen wir herausbekommen, auf welcher Partition wir uns eigentlich befinden und wo sie im Verzeichnisbaum eingehängt ist. Wir geben den Befehl df ohne weitere Parameter ein. Die Ausgabe lautet:

/dev/hda2 2071328 1047620 918484 53% /
/dev/hda5 3099108 1737192 1204484 59% /usr
/dev/hda6 2071296 767708 1198364 39% /opt
/dev/hda7 2071296 215212 1750860 11% /home

Nachdem wir uns im Verzeichnis /usr/local/data befinden, können wir also aus dieser Ausgabe schließen, daß wir uns auf der Partition /dev/hda5 befinden und daß diese Partition ins Verzeichnis /usr gemountet ist. Jetzt rufen wir den find-Befehl auf und weisen ihn an, ab dem Verzeichnis /usr alle Dateien zu suchen, die die Inode 92550 benutzen. Zusätzlich weisen wir ihn noch darauf hin, daß er nur dieses eine Dateisystem durchsuchen soll. Dazu kennt find die Option -xdev. Wir geben folgenden Befehl ein:

find /usr -xdev -inum 92550 -print

Der Befehl find sucht ab dem Verzeichnis /usr aber nur innerhalb der Partition (-xdev) alle Dateien, die die Inode 92550 (-inum 92550) besitzen. Die gefundenen Dateien werden ausgegeben (-print). Die Anweisung -print hätten wir unter Linux auch weglassen dürfen, es ist hier die voreingestellte Aktion. Das Ergebnis sieht dann etwa wie folgt aus:

/usr/lib/Beispiel/Datei.txt
/usr/local/data/BEISPIEL.DAT
/usr/local/lib/Beispiel/Noch_eine
/usr/openwin/Hier_auch
/usr/src/abc

Hätten wir dem find-Befehl statt der Aktion -print die Aktion -ls mitgegeben, die alle gefundenen Dateien im selben Format wie ls -dils ausgibt, dann hätten wir die folgende Ausgabe bekommen:

92550 5 -rw-r–r– 1 root root 1895 Apr 8 15:02 /usr/lib/Beispiel/Datei.txt
92550 5 -rw-r–r– 1 root root 1895 Apr 8 15:02 /usr/local/data/BEISPIEL.DAT
92550 5 -rw-r–r– 1 root root 1895 Apr 8 15:02 /usr/local/lib/Beispiel/Noch_eine
92550 5 -rw-r–r– 1 root root 1895 Apr 8 15:02 /usr/openwin/Hier_auch
92550 5 -rw-r–r– 1 root root 1895 Apr 8 15:02 /usr/src/abc

Eine weitere Möglichkeit der Identifikation von Hardlinks wäre es, ein ls -ilR Kommando (langes Listing mit Inode-Nummern, rekursiv) auszuführen und dessen Ausgabe an grep weiterzuleiten. Grep würde dann nach der entsprechenden Inode-Nummer am Zeilenanfang suchen. Also für unser obiges Beispiel etwas in der Art:

ls -ilR /usr | grep „^ *92550“

Das hat allerdings den Nachteil, daß wir nicht festlegen können, daß nur die Dateien innerhalb einer Partition gesucht werden. Zum anderen ist diese Art der Suche wesentlich langsamer als die mit dem find-Befehl.

Kopieren symbolischer Links
Wenn ein symbolischer Link mit dem Befehl cp kopiert wird, ohne daß dazu bestimmte Optionen gegeben werden, so wird nicht etwa der Link kopiert, sondern die Datei, auf die der Link zeigt. Das Ergebnis (die Zieldatei) ist jetzt also kein Link, sondern eine reguläre Datei. Man spricht in diesem Zusammenhang von der Dereferenzierung eines Links.

Dereferenzierung bedeutet, daß der Link zurückverfolgt wird, und durch das ausgetaucht wird, auf das er zeigt.

Um das zu vermeiden, muß dem cp-Befehl eine spezielle Option mitgegeben werden, die diese Dereferenzierung unterbindet. Wenn wir also einen symbolischen Link als solchen kopieren wollen, das heißt wenn das Ziel der Kopieraktion wiederum ein Link sein soll, so müssen wir dem Kopierbefehl die Option -d oder –no-dereference mitgeben.

Aber bitte Vorsicht walten lassen! Wenn ein symbolischer Link als Link kopiert wird, dann wird der Link genauso kopiert, wie er war. Falls er keine absolute, sondern eine relative Pfadangabe zu dem Objekt beinhaltet, auf das er verweist, so wird die Kopie genau die Selbe Pfadangabe haben. Es ist nicht gewährleistet, daß diese Angabe von der neuen Lokalität aus immer noch stimmt.

Am Rande bemerkt: Der cp-Befehl ist selbst auch in der Lage, Links zu erzeugen statt Dateien zu kopieren. Mit der Option -l erzeugt er Hardlinks statt Kopien und mit -s symbolische Links.

Verwenden von Links zur Systemadministration
In der Systemverwaltung werden Links auf vielfältige Weise eingesetzt. Dabei kommen sowohl Hard- als auch symbolische Links zur Anwendung. Ein paar Beispiele:

Vermeidung versehentlichen Löschens mit Hardlinks
Wichtige Systemdateien können an andere Orte gelinkt werden, wo sie sozusagen eine Versicherung gegen versehentliches Löschen bieten. Nehmen wir an, Sie erstellen ein Verzeichnis /etc2 und verlinken alle wichtigen Dateien in /etc mit Hardlinks in dieses Verzeichnis. Sollte jetzt eine Datei in /etc gelöscht werden, so steht sie uns immer noch in der aktuellsten Version in /etc2 zur Verfügung.
Zentrale Verwaltung wichtiger Startdateien in den Userverzeichnissen
Jeder User hat in seinem Home-Verzeichnis verschiedene Startdateien oder andere Konfigurationsdateien. Soll sichergestellt werden, daß alle User immer die gleichen Einstellungen besitzen, so könnten all diese Dateien Hardlinks auf einen Prototyp sein. Wenn der Systemverwalter jetzt für alle User eine Veränderung vornehmen will, so muß er nur eine dieser Dateien (etwa den Prototyp) verändern und alle Dateien der User sind mitverändert.
Symbolische Links auf Verzeichnisse
Wenn bestimmte Teile des Verzeichnisbaums ReadOnly gemountet sein sollen, aber andererseits Unterverzeichnisse dieser Teile beschreibbar sein müssen, so können diese Unterverzeichnisse symbolische Links auf andere Unterverzeichnisse sein, die nicht auf ReadOnly-gemounteten Partitionen liegen. Das /usr Verzeichnis wird z.B. gerne ReadOnly gemountet, enthält aber Verzeichnisse wie tmp oder spool, die beschreibbar sein müssen. Diese Verzeichnisse sind oft symbolische Links auf entsprechende Verzeichnisse unter /var. Dort sind diese Verzeichnisse tatsächlich beschreibbar.

Allgemein

1.104.6 – Verwaltung von Dateieigentum

Schreibe einen Kommentar

Prüfungskandidaten sollten in der Lage sein, den Benutzer- und Gruppenbesitz von Dateien zu steuern. Dieses Lernziel beinhaltet das Ändern des Besitzers und der Gruppenzugehörigkeit einer Datei sowie des Standardeigentümers von neuen Dateien.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* chmod
* chown
* chgrp
Im letzten Abschnitt haben wir gesehen, wie Zugriffsrechte gesetzt bzw. verändert werden. All diese Zugriffsrechte beziehen sich ja auf Eigentümer bzw. Gruppen von Usern. Von daher benötigen wir noch die Technik, Eigentümer und Gruppenzugehörigkeit einer Datei zu verändern. Dazu gibt es die Programme chown und chgrp. Diese Programme sollen hier vorgestellt werden.

Ändern des Dateieigentümers mit chown
Um den Eigentümer einer Datei zu wechseln bzw. besser ausgedrückt, eine Datei einem anderen User zu übereignen, existiert das Programm chown. Dieses Programm darf nur vom Systemverwalter ausgeführt werden, ein normaler User kann also nicht seine Dateien anderen Usern übereignen.

Das Programm chown hat eine einfache Aufrufform:

chown [Optionen] Username Datei(en)
chown [Optionen] [Username][.][Gruppenname] Datei(en)
chown [Optionen] –reference=Referenzdatei Datei(en)

Eine oder mehrere Dateien bekommen so als Eigentümer den genannten Usernamen zugewiesen. Der Username kann hier entweder als Name oder als Nummer (UserID – UID) angegeben werden.

Wenn nur ein Username oder eine UserID angegeben wurde, so wird dieser User zum Eigentümer jeder angegebenen Datei und die Gruppenmitgliedschaft der Dateien wird nicht verändert. Wenn dem Username ein Doppelpunkt oder Punkt und ein Gruppenname (oder eine GruppenID) ohne Leerzeichen folgt, dann wird auch die Gruppenzugehörigkeit der Dateien geändert. Wenn dem Usernamen ein Punkt oder Doppelpunkt folgt, aber kein Gruppenname angegeben wird, so wird der angegebene User zum Eigentümer der angegebenen Dateien und die Dateien bekommen die Gruppenzugehörigkeit zu der Gruppe, die die Login-Gruppe dieses Users ist (die Gruppe, die im Gruppenfeld in /etc/passwd für diesen User angegeben ist). Wenn aber der Username weggelassen wurd, aber ein Punkt oder Doppelpunkt, gefolgt von einem Gruppennamen angegeben wurde, so wird nur die Gruppenzugehörigkeit der Dateien verändert, der Eigentümer bleibt unverändert. In diesem Fall arbeitet chown genau wie chgrp.

Wenn statt einem Usernamen und/oder Gruppennamen die Option –reference=Referenzdatei angegeben wurde, so werden Eigentümer und Gruppenzugehörigkeit der angegebenen Dateien so gesetzt, wie die der Referenzdatei.

Wird als Option ein -R oder ein –recursive angegeben, so verändert chown die Eigentümer eines ganzen Verzeichnisbaums, inclusive aller enthaltenen Dateien und Unterverzeichnisse.

Ändern der Gruppenzugehörigkeit einer Datei mit chgrp
Die Gruppenzugehörigkeit einer Datei kann auch mit dem Befehl chgrp gewechselt werden. Die Aufrufform ist ähnlich der von chown:

chgrp [Optionen] Gruppe Datei(en)

Auch hier kann die Gruppe wieder entweder als Gruppenname oder als GruppenID angegeben werden. Die Benutzung von chgrp ist nur dem Eigentümer und dem Superuser (root) erlaubt. Der Eigentümer kann eine Datei nur den Gruppen zuordnen, denen er selbst auch angehört.

Wie schon bei chown und chmod kann auch chgrp mit der Option -R oder –recursive ein ganzer Verzeichnsast rekursiv bearbeitet werden, d.h., daß alle Verzeichnisse und enthaltene Dateien bearbeitet werden.
Sicherstellen der Gruppenzugehörigkeit von Dateien in Verzeichnissen
Wenn ein Verzeichnis für eine bestimmte Gruppe von Usern beschreibbar ist und diese User darin eine gemeinsame Arbeit leisten sollen, so wäre es ja praktisch, wenn alle User innerhalb dieses Verzeichnisses alle Dateien, die sie anlegen, eben der Gruppe zuweisen, der das Verzeichnis angehört. Das ist aber nicht automatisch der Fall.

Jeder User kann beliebig vielen Gruppen angehören. er ist aber immer Mitglied einer sogenannten Login-Gruppe (manchmal auch Initialgruppe genannt). Wenn ein User eine Datei anlegt, so wird diese Datei normalerweise die Gruppenzugehörigkeit der Login-Gruppe dieses Users zugewiesen bekommen.

Um sicherzustellen, daß alle Dateien in einem bestimmten Verzeichnis beim Anlegen immer die Gruppenzugehörigkeit zu der Gruppe bekommen, der das Verzeichnis gehört, muß das Verzeichnis das SGID-Bit gesetzt bekommen. Das wird mit dem Befehl chmod eingestellt, wie auf der letzten Seite beschrieben.

Wenn ein User allerdings nur vorübergehend die Standard-Gruppe wechseln will, so steht im dazu das Kommando newgrp zur Verfügung. Das würde allerdings das Mitdenken aller User voraussetzen, was immer eine Schwachstelle bedeutet…

Wenn also der Systemverwalter ein Verzeichnis für eine bestimmte Projektarbeit anlegt, tut er gut daran, diesem Verzeichnis das SGID-Bit zu setzen, um die Gruppenmitgliedschaft der Dateien in diesem Verzeichnis von vorneherein festzulegen.

Allgemein

1.104.5 – Zugriffsrechte

Schreibe einen Kommentar

1.104.5 – Zugriffskontrolle auf Dateien mittels Zugriffsrechten
Prüfungskandidaten sollten in der Lage sein, Dateizugriff mittels Zugriffsberechtigungen zu steuern. Dieses Lernziel beinhaltet Zugriffsrechte auf reguläre und spezielle Dateien sowie Verzeichnisse. Ebenfalls enthalten sind Zugriffsmodi wie suid, sgid und sticky bit, die Verwendung des Gruppenfeldes für die Vergabe von Zugriffsrechten an Arbeitsgruppen, das immutable flag und der voreingestellte Dateierstellungsmodus.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* chmod
* umask
* chattr
Die Zugriffsrechte unter Linux/Unix sind im Prinzip sehr einfach aufgebaut, jedoch aber auch sehr wirkungsvoll, wenn man weiß, wie sie im Einzelnen angewandt werden. Das Wissen um diese Rechte ist absolutes Grundwissen für alle, die mit Systemverwaltung unter Linux beschäftigt sind und sollte daher im Schlaf beherrscht werden.

Grundsätzlicher Aufbau von Zugriffsrechten
Jede Datei in einem Linux-System – also auch Gerätedateien, Sockets, Pipes, Verzeichnisse, usw. – besitzt in ihrer Inode eine Angabe über die Zugriffsrechte. Außerdem hat jede Datei genau einen Eigentümer und genau eine Gruppe, der sie zugehört. Die Zugriffsrechte beziehen sich immer auf eben diesen Eigentümer der Datei, auf Gruppenmitglieder der Gruppe, der die Datei angehört und auf den Rest der Welt.

Für diese drei Kategorien (Eigentümer, Gruppe, Rest) existiert jeweils eine Angabe, die beschreibt, ob die Datei für die jeweilige Kategorie lesbar (r), beschreibbar (w) und ausführbar (x) ist.

Der Befehl ls -l Dateiname zeigt uns für jede Datei eben diese Angaben. So bedeutet die Ausgabe:

-rw-r—– 1 hans autoren 1519 Jul 29 2000 Testdatei

Die Datei Testdatei ist eine reguläre Datei (-). Sie gehört dem User hans, der sie lesen und verändern darf (rw-). Die Datei gehört zur Gruppe autoren. Mitglieder dieser Gruppe dürfen die Datei lesen (r–). Der Rest der Welt hat keinerlei Rechte auf diese Datei (—).

Das erste Zeichen der Ausgabe zeigt uns also, um was für eine Art Datei es sich handelt. Folgende Dateiarten sind unter Linux definiert:

Zeichen Dateiart
– 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)

Das dem ersten Zeichen folgende Konstrukt ist die Beschreibung des Zugriffsmodus. Die ersten drei Zeichen beschreiben die Rechte des Eigentümers der Datei, die nächsten drei die Rechte eines Gruppenmitglieds der Gruppe, der auch die Datei zugehört und die letzten drei die Rechte aller anderen User. Ein r bedeutet Leserecht (read), ein w Schreibrecht (write) und ein x Ausführungsrecht (execute). Diese Rechte können numerisch dargestellt werden. Dazu werden die Rechte wie folgt bezeichnet:

Eigentümer Gruppenmitglied Rest der Welt
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Die Nummern werden für jede der drei Kategorien einzeln addiert. Ein Zugriffsrecht von rw-r—– wäre so also numerisch darstellbar als 640. Die 6 errechnet sich aus dem r (4) plus w (2) des Eigentümerrechtes, die 4 ist einfach das Leserecht (r) des Gruppenmitglieds und die 0 entspricht keinem gesetzten Recht.

Für reguläre Dateien sind diese Rechte einfach zu durchschauen. Das Leserecht bedeutet, daß der Inhalt der Datei gelesen werden darf. Das Schreibrecht bedeutet, daß der Inhalt der Datei verändert werden darf (und somit die Datei auch gelöscht werden darf) und das Ausführungsrecht bedeutet, daß die Datei ein Programm ist, das ausgeführt werden darf.

Etwas anders sieht es mit Verzeichnissen aus. Hier bedeutet das Leserecht, daß der Inhalt eines Verzeichnisses aufgelistet werden darf, das Schreibrecht, daß Dateien im Verzeichnis angelegt und gelöscht werden dürfen und das Ausführungsrecht, daß in das Verzeichnis gewechselt werden darf. Das hat einen Haken, zu dem wir später noch kommen werden. Hat nämlich ein User Schreibrecht auf ein Verzeichnis, so darf er darin auch Dateien löschen, auf die er selbst keinerlei Rechte besitzt. Das liegt an der Tatsache, daß ein Verzeichnis genau genommen nur eine Datei ist, die Dateinamen und die dazu passenden Inode-Nummern gespeichert hat. Eine Datei in einem Verzeichnis ist also letztlich nichts anderes als eine Zeile Text in einer Textdatei. Und wer Schreibrechte auf eine Textdatei hat, kann Zeilen daraus löschen!
Spezielle Rechte
Neben diesen sichtbaren Rechten existieren noch drei weitere, die man sich als weitere (führende) Nummer vorstellen kann. Dabei handelt es sich um das Substitute UserID Bit (4), das Substitute GroupID Bit (2) und das Sticky Bit (1).

Substitute UserID Bit (SUID)
Dieses Recht gilt ausschließlich für ausführbare Dateien. 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. Jeder User, der dieses Programm ausführt, tut dies unter der effektiven UserID des Users, dem die Datei gehört.

So hat z.B. das Programm /usr/bin/passwd die Aufgabe, daß auch normale User damit ihr eigenes Passwort ändern können. Dieses Passwort wird aber gespeichert in einer Datei, die nur von root beschrieben werden darf. Das Programm /usr/bin/passwd hat als Eigentümer root und hat das Substitute UserID Bit gesetzt. Jeder User, der dieses Programm ausführt tut dies also unter der effektiven UserID von root und hat daher die Rechte von root während der Ausführung. Das ermöglicht es dem Programm, das veränderte Passwort zu speichern.

Das ist beim Passwort-Programm nicht weiter problematisch, eine richtige Sicherheitslücke entsteht, wenn eine Shell mit diesem Bit ausgestattet ist und als Eigentümer root hat. Dann könnte jeder User, der diese Shell ausführt, root-Rechte benutzen!

Substitute GroupID Bit (SGID)
Dieses Recht gilt einerseits für ausführbare Dateien und andererseits für Verzeichnisse. Hat ein ausführbares Programm dieses Recht gesetzt, so gilt der gleiche Mechanismus, wie beim Substitute UserID Bit, nur diesmal eben die Gruppenmitgliedschaft betreffend. Ein User, der dieses Programm ausführt, tut dies als Gruppenmitglied der Gruppe, der das Programm gehört, statt seiner eigentlichen Gruppenkennung. Er hat also die Rechte eines Gruppenmitglieds dieser Gruppe, auch wenn er selbst nicht Mitglied dieser Gruppe ist. Statt dem x beim Gruppenrecht stellt das ls -l Kommando hier ein s dar.

Hat ein Verzeichnis dieses Recht gesetzt, dann liegt der Fall etwas anders. Legt ein User, der Schreibrecht auf ein Verzeichnis hat, in diesem Verzeichnis eine Datei an, so erhält diese Datei normalerweise die Gruppenmitgliedschaft der primären Gruppe des Users, der sie eben angelegt hat. Das führt schnell zum Chaos, wenn z.B. mehrere User zusammen an einem Projekt arbeiten. Alle diese User sind Gruppenmitglieder einer bestimmten Gruppe, aber sie haben diese Gruppe nicht als primäre Gruppe. Das heißt, es kann sein, daß die einzelnen User die Dateien der jeweils anderen Projektmitarbeiter nicht lesen können. Wenn dieses Verzeichnis aber der gemeinsamen Gruppe gehört und eben das Substitute GroupID Bit darauf gesetzt ist, dann werden Dateien in diesem Verzeichnis grundsätzlich unter der GruppenID abgespeichert, der das Verzeichnis gehört. Mit diesem Mechanismus sind Arbeitsverzeichnisse für bestimmte Projektgruppen realisierbar.

Sticky Bit
Das Sticky Bit hat nur eine Bedeutung für Verzeichnisse. Oben wurde schon das Problem erwähnt, daß ein User, der Schreibrecht auf ein Verzeichnis hat, innerhalb dieses Verzeichnisses alle Dateien löschen kann, auch wenn sie ihm nicht gehören und er keinerlei Rechte auf diese Dateien besitzt. Das wird durch das Sticky Bit verhindert.

Ein Verzeichnis in dem jeder User Schreibrecht haben muß, wie etwa das /tmp-Verzeichnis, sollte unbedingt dieses Bit gesetzt haben. Ansonsten kann ein böswilliger User dort die Dateien anderer User löschen.

Das gesetzte Sticky-Bit wird vom ls -l Kommando durch ein t statt des x in der Kategorie „Rechte des Restes der Welt“ dargestellt.

Um diese speziellen Rechte auch numerisch darzustellen, wird vor den oben genannten „normalen“ Rechten noch eine Oktalziffer angefügt, so daß sich das folgende Bild ergibt:

Sonderrechte Eigentümer Gruppenmitglied Rest der Welt
SUID SGID Sticky r w x r w x r w x
4 2 1 4 2 1 4 2 1 4 2 1

Ein Recht von 4755 bedeutet also, daß das Substitute UserID Bit gesetzt ist (4), der Eigentümer Lese-, Schreib- und Ausführungsrechte (1+2+4=7) hat während sowohl Gruppenmitglieder, als auch der Rest der Welt nur Lese- und Ausführungsrecht (1+4=5) besitzen.

Ändern von Zugriffsrechten mit chmod
Um die oben beschriebenen Rechte vergeben bzw. ändern zu können existiert das Programm chmod (change mode). Es erlaubt, die Rechte von Dateien und Verzeichnisse zu verändern. Die prinzipielle Anwendung ist einfach:

chmod [Optionen] Modus Datei(en)

Die wichtigste Option ist dabei -R oder –recursive, mit dem ganze Unterverzeichnisse mit allen Dateien darin auf einmal bearbeitet werden können.

Als Modus kann entweder ein numerischer, oder ein symbolischer Modus angegeben werden. Der numerische Modus entspricht genau dem, was im letzten Abschnitt dieser Seite beschrieben wurde, er wird hier nicht nochmal erklärt. Nur ein kurzes Beispiel noch, der Aufruf

chmod 644 foo.txt

würde der Datei foo.txt ein Zugriffsrecht von rw-r–r– geben. Mit numerischem Modus ist grundsätzlich immer ein absoluter Wert gesetzt, egal, welche Rechte vorher gesetzt waren.

Der symbolische Modus besteht aus einer Angabe der Rechte durch 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) und das a steht für all (Alle). Wird dieses führende Zeichen weggelassen, dann wird standardmäßig a (Alle) angenommen.

Vorsicht, oft wird diese Angabe verwechselt und das o mit dem Begriff Owner (Eigentümer) verwechselt. 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 Rechenzeichen +, – oder = beschreibt, ob ein Recht den bestehenden Rechten hinzugefügt (+) werden soll, davon abgezogen (-) werden soll oder absolut (=) gesetzt werden soll.

Dem Rechenzeichen folgt die Angabe der zu setzenden (oder addierenden oder subtrahierenden) Rechte in der Form einer Zeichenkette, die aus den Buchstaben r,w,x,s,t,u,g,o besteht. Dabei meinen r, w und x wie üblich Read, Write und Execute. Wird dem User das s-Recht gesetzt, so meint das das Substitute UserID Bit (beispielsweise durch u+s), bekommt hingegen die Gruppe dieses Recht, so ist das Subtitute GroupID Bit gemeint (g+s). Das t steht für das Sticky-Bit und kann nur dem Rest der Welt vergeben werden (o+t).

Folgen dieser Angabe noch ein u, g oder o, so ist dies ein Ausschlußkriterium in Verbindung mit dem a am Anfang. Das nachgestellte u, g oder a schützt also die Rechte der User, Gruppenmitglieder bzw. Anderen vor Veränderung.

Das ganze kann jetzt mehrmals hintereinander angewandt werden, indem mehrere solcher Modi durch Kommas getrennt angegeben werden. So ist es etwa möglich zu schreiben:

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

um dem Programm foo das Recht rwxr-x— zu setzen. Gewöhnlich tut man sich aber in diesem Fall leichter mit einer numerischen Angabe (hier 750).

Das praktische an der symbolischen Angabe von 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.

Wird als Option ein -R oder ein –recursive angegeben, so verändert chmod die Rechte eines ganzen Verzeichnisbaums, inclusive aller enthaltenen Dateien und Unterverzeichnisse.

Voreingestellten Zugriffsmodus mit umask bestimmen
Es bleibt jetzt natürlich die Frage, welche Zugriffsberechtigungen beim Anlegen einer Datei verwendet werden. Um das festzulegen, kennt Unix das Kommando umask, dessen Anwendung aber etwas merkwürdig ist.

Der Befehl umask erwartet eine Maske als Parameter, die sich auf den Zugriffsmodus bezieht, den neu zu erstellende Dateien bekommen sollen. Das Wort Maske bedeutet, daß nicht die Werte eingegeben werden, die gesetzt werden sollen, sondern umgekehrt, die Werte, die nicht gesetzt (maskiert) werden sollen. Die einfachste Möglichkeit besteht darin, die gewünschten oktalen Werte jeweils von 7 abzuziehen:

Wollen wir z.B. dafür sorgen, daß alle unsere Dateien die Zugriffsberechtigung rw-r—– bekommen, also Lese-und Schreibrecht für den Eigentümer, Leserecht für Gruppenmitglieder und keine Rechte für den Rest der Welt, dann entspräche das der oktalen Darstellung 640.

Die dafür notwendige umask wäre dann:

7-6=1
7-4=3
7-0=7

Mit dem Befehl

umask 137

würden also alle Dateien, die wir anlegen die gewünschte Zugriffsberechtigung 640 bekommen. Das hat noch einen kleinen Haken, weil die Verzeichnisse, die wir erstellen würden auch diesen Modus bekämen. Damit wäre für uns selbst das Durchsuchungsrecht (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. 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 dieser umständlichen Methode gibt es aber auch die symbolische Form, die die Rechte direkt bezeichnet. 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 seine Voreinstellung also selbst einstellen, eine der wenigen Möglichkeiten, mit denen er dem Systemverwalter ins Handwerk pfuschen kann, wenn der versucht, sein System sicher zu machen. Allerdings bezieht sich diese Einstellung ja nur auf die neu anzulegenden Dateien des jeweiligen Users…
Erweiterte Dateiattribute im EXT2-Dateisystem
Dateien auf EXT2-Dateisystemen besitzen neben den oben genannten Attributen noch weitere, die einen zusätzlichen Schutz bieten können. Diese Attribute können mit dem Befehl lsattr angezeigt und mit chattr verändert (gesetzt) werden.

Die wichtigsten dieser Attribute sind:

a (append)
Eine Datei mit a-Attribut kann schreibend nur im Anhängen-Modus geöffnet werden. Das bedeutet, daß ein User, der Schreibrecht auf diese Datei hat, zwar Daten an das Ende der Datei anhängen kann (etwa durch die Verwendung der >>-Umleitung), jedoch keine Veränderungen am bestehenden Inhalt der Datei vornehmen darf. Nur der Superuser kann dieses Attribut setzen oder entfernen.
i (immutable)
Eine Datei mit gesetztem i-Attribut kann nicht modifiziert werden. Sie kann weder gelöscht, noch umbenannt werden, es kann kein Hardlink auf sie angelegt werden und keine Daten können angehängt werden. Nur der Superuser kann dieses Attribut setzen oder entfernen.
s (save-delete)
Wenn eine Datei das s-Attribut gesetzt hat, werden alle Blöcke dieser Datei beim Löschen der Datei mit Nullzeichen überschrieben. Dadurch ist die Datei auch durch Methoden wie dem Dateisystemdebuger nicht wieder herstellbar oder ihr Inhalt ist nicht mehr einsehbar, wenn sie einmal gelöscht wurde.

Eine Liste aller möglichen Attribute entnehmen Sie der Handbuchseite von chattr.

Notizen zu Open Source, Linux, Informatik, Physiologie, Umfragen, Tai Chi, Rezepte, Blumen und für mich Interessantes eben