SelfLinux Grundlagen Benutzer- und Berechtigungskonzepte unter Linux Abschnitt 5 | SelfLinux-0.13.0

| Benutzer- und Berechtigungskonzepte unter Linux | Autoren Formatierung GPL

#### 5 Berechtigungsklassen: Lesen, Schreiben und Ausführen

Da unter Unix letztlich alle Ein- und Ausgabeoperationen mit denselben Systemrufen vorgenommen werden, hat sich der Ausspruch Alles ist eine Datei! etabliert. Beispielsweise sind auch Verzeichnisse letztlich - wie alle anderen Einträge im Dateisystem - eine besonderer Typ Datei. Weitere Typen sind etwa Character- und Blockdevices, benamte Pipes, reguläre Dateien, symbolische Links und Sockets. Für jeden dieser Dateitypen haben die unterschiedlichen Rechte (Lesen, Schreiben und Ausführen) eine unterschiedliche Bedeutung.

Im Sinne einer minimalistischen Philosophie wurde dennoch die Abstraktion vorgenommen, alle diese unterschiedlichen Operationen unter dem Begriff der Datei zusammenzufassen und einheitliche Zugriffsmethoden bereitzustellen. Sowohl für den Entwickler wie auch für den Administrator bedeutet diese Abstraktion eine Vereinfachung seiner Aufgaben. Beispielsweise erfolgt die Vergabe des Leserechtes für reguläre Dateien auf exakt dieselbe Weise wie die Vergabe des Leserechtes für ein Sounddevice.

Da die Bedeutung der Lese-, Schreib- und Ausführrechte für die einzelnen Dateitypen im einzelnen besser bei den verschiedenen Spezialthemen besprochen werden kann, sollen im Folgenden lediglich die unterschiedlichen Bedeutungen dieser Rechte für reguläre Dateien und Verzeichnisse erläutert werden. Reguläre Dateien sind Dateien mit definierten Dateiformaten, darunter etwa gewöhnliche Textdateien, Bildformate, Sounddateien, aber auch Programmdateien (Executables). Die Anzahl an Dateiformaten füllt ganze Enzyklopädien. Verzeichnisse sind Dateien, die einen Katalog von Dateien und Unterverzeichnissen enthalten können.

#### 5.1 Lesen

#### 5.1.1 Leserecht für Dateien

Für Datendateien aller Art, wie z.B. Textdateien, Bilder usw., leuchtet das Leserecht unmittelbar ein: Die Datei kann zur Ansicht geöffnet und ihr Inhalt angezeigt oder abgespielt werden. Für Programmdateien ist das Leserecht weniger intuitiv verständlich. Manchen mag es überraschen, dass für die Ausführung eines Programms nicht das Leserecht gesetzt sein muss:

user@linux ~$ su Password: (Eingabe) root@linux ~# chmod a-r /bin/echo root@linux ~# ls -l /bin/echo --wx--x--x 1 root root 7064 2002-09-09 20:05 /bin/echo root@linux ~# exit user@linux ~$ echo hallo hallo

Mittels des chmod Kommandos wurde der Programmdatei des echo Kommandos temporär das Leserecht entzogen. Dennoch ist echo weiterhin verwendbar. Für manchen erscheint dies widersprüchlich, da zur Ausführung eines Programmes schließlich die Programmdatei eingelesen werden muss. Dies ist jedoch nicht notwendig. Das Laden eines Programmes ist sowohl technisch als auch konzeptionell ein völlig anderer Vorgang als das Lesen einer Datei. Dass root eine Sonderstellung einnimmt, zeigen übrigens die folgenden Kommandos:

user@linux ~$ wc /bin/echo wc: /bin/echo: Keine Berechtigung user@linux ~$ su Password: (Eingabe) root@linux ~# wc /bin/echo 36 234 7064 /bin/echo root@linux ~# chmod a+r /bin/echo root@linux ~# exit user@linux ~$ wc /bin/echo 36 234 7064 /bin/echo

Trotz fehlendem Leserecht durfte root mittels des wc Kommandos die Datei lesen, nämlich die Anzahl der Zeilen, Worte und Zeichen in der Datei zählen (eine nicht unbedingt sinnvolle Aktion, die hier nur zur Demonstration der Sonderstellung von root durchgeführt wurde). Der angemeldete Standardbenutzer durfte wc nicht auf die Datei anwenden und erhielt einen Berechtigungsfehler.

#### 5.1.2 Leserecht für Verzeichnisse

Da Verzeichnisse keine Daten im eigentlichen Sinne enthalten, sondern lediglich Information über Dateien und Unterverzeichnisse, hat das Leserecht hier freilich eine andere Bedeutung. Das klassische Kommando zum Auslesen von Verzeichnisinformation ist ls. Betrachten wir ein Verzeichnis testdir, das eine Textdatei textfile und das Programm tipptrainer enthält.

user@linux ~$ ls -l | grep testdir drwxr-xr-x 2 matthias users 104 2002-11-05 23:43 testdir user@linux ~$ ls -l testdir insgesamt 408 -rw-r--r-- 1 matthias users 0 2002-11-05 23:43 testfile -rwxr-xr-x 1 matthias users 417072 2002-11-05 23:43 tipptrainer

Das erste Kommando zeigt die aktuellen Berechtigungen für das Testverzeichnis. Die Leserechte sind für alle drei Benutzerklassen gesetzt. Folglich ist das zweite Kommando beim Auslesen des Verzeichnisses erfolgreich und gibt den Verzeichnisinhalt aus. Das Entfernen des Leserechtes hat ebenfalls den erwarteten Effekt:

user@linux ~$ chmod a-r testdir user@linux ~$ ls -l testdir ls: testdir: Keine Berechtigung

Es ist jedoch wichtig festzuhalten, dass damit keineswegs das Leserecht für die enthaltenen Dateien entfernt wurde:

user@linux ~$ ls -l testdir/testfile -rw-r--r-- 1 matthias users 0 2002-11-05 23:43 testdir/testfile user@linux ~$ cat testdir/testfile Dies ist eine Testdatei. user@linux ~$ testdir/tipptrainer & [1] 7761

Es dürfen sowohl die Berechtigungen der Testdatei wie auch ihr Inhalt ausgelesen werden. Das Programm tipptrainer lässt sich ebenfalls problemlos starten. Das Entfernen des Leserechtes für ein Verzeichnis wirkt sich also keineswegs auf die Dateien und Unterverzeichnisse aus, welche in dem Verzeichnis abgelegt sind. Es ist wichtig, dies zu verstehen, da ansonsten die Illusion entstehen könnte, mit dem Entfernen des Leserechtes für ein Verzeichnis schütze man auch dessen Inhalt vor dem Zugriff.

Es ist hilfreich, sich ein Verzeichnis als einen Katalog vorzustellen: Sein Inhalt ist eine Liste der Knoten, die sich innerhalb des Dateibaumes unterhalb des Verzeichnisses befinden. Das Leserecht ermöglicht das Auslesen der Kataloginformation, beispielsweise mittels des ls Kommandos. Ein Entfernen des Leserechtes verbietet zwar das Auslesen des Kataloges, nicht aber den Zugriff auf die katalogisierten Inhalte.

Das Leserecht eines Verzeichnisses hat auch keinerlei Auswirkung darauf, ob Verzeichnisinhalte gelöscht oder angelegt werden dürfen. Da bei diesen Operationen kein lesender, sondern ein schreibender Zugriff auf den "Kataloginhalt" erfolgt, spielt das Leserecht hier keine Rolle:

user@linux ~$ rm testdir/testfile user@linux ~$ touch testdir/testfile2

Eine interessante Ausnahme bildet die Verwendung von Wildcards:

user@linux ~$ rm testdir/* rm: Entfernen von "testdir/*" nicht möglich: Datei oder Verzeichnis nicht gefunden user@linux ~$ chmod a+r testdir user@linux ~$ rm testdir/* user@linux ~$ ls -l testdir insgesamt 0

Um den * durch Dateinamen zu ersetzen, welche schließlich dem rm Kommando übergeben werden, muss die Shell lesend auf das Verzeichnis zugreifen können. Da kein Leserecht gesetzt war, liefert dieser Zugriff kein Ergebnis, und das rm Kommando schlägt mangels übergebener Argumente (d.h. Dateinamen) fehl. Nach Vergabe des Leserechtes wird der * durch die Dateinamen im Testverzeichnis ersetzt und diese an das rm Kommando zum Löschen übergeben. Die Verwendung von Wildcards zur Dateinamensubstituation erfordert folglich ein Leserecht für das betroffene Verzeichnis.

#### 5.2 Schreiben

#### 5.2.1 Schreibrecht für Dateien

Das Schreibrecht für reguläre Dateien ist ebenso intuitiv verständlich wie das Leserecht. Ist dieses Recht gesetzt, darf die Datei überschrieben oder weiterer Inhalt an sie angehängt werden. Das Schreiben auf Spezialdateien wie z.B. Sockets, Framebuffer oder Gerätedateien erfordert ebenfalls ein hundsgemeines Schreibrecht. Insbesondere wenn man solche Dateien selbst erzeugt hat (z.B. um ein ungewöhnliches Gerät in das System zu integrieren) sollte man nicht vergessen, das Schreibrecht zu setzen - ein trivialer Umstand, der schon so manche Arbeitsstunde gekostet hat.

#### 5.2.2 Schreibrecht für Verzeichnisse

Erwartungsgemäß bezieht sich das Schreibrecht für Verzeichnisse auf das Anlegen und Löschen von Dateien in Verzeichnissen. Ohne Schreibrecht ist weder das eine noch das andere möglich.

user@linux ~$ ls -l | grep testdir drwxr-xr-x 2 matthias users 48 2002-11-06 00:08 testdir user@linux ~$ touch testdir/testfile user@linux ~$ chmod a-w testdir user@linux ~$ rm testdir/testfile rm: Entfernen von "testdir/testfile" nicht möglich: Keine Berechtigung user@linux ~$ touch testdir/testfile2 touch: Erzeugen von "testdir/testfile2": Keine Berechtigung

Eine andere Bedeutung kommt dem Schreibrecht für Verzeichnisse nicht zu. Insbesondere benötigt man kein Schreibrecht in einem Verzeichnis, um eine darin enthaltene Datei oder auch nur deren Rechte zu ändern. Da diese Information direkt in die Datei bzw. deren Inode geschrieben wird, ist das Schreibrecht des Verzeichnisses ohne Belang:

user@linux ~$ echo hallo > testdir/testfile user@linux ~$ chmod +r testdir/testfile

#### 5.3 Ausführen

#### 5.3.1 Ausführrecht für Dateien

Programme und Skripte sind es, die ausgeführt werden können. Programme liegen in Binärformaten vor - unter Linux hat sich das Executable and Linking Format (ELF) durchgesetzt, aber auch andere Formate werden unterstützt. Skripte werden von Interpretern ausgeführt und liegen in Textformat vor.

Bei Programmen, d.h. Dateien in einem ausführbaren Binärformat, liegt die Sache einfach. Ist das Ausführrecht gesetzt, darf das Programm aufgerufen und ausgeführt werden. Zunächst wird die Berechtigung geprüft und danach versucht, das Programm zu laden. Diese Reihenfolge zeigt der Versuch, eine Datei eines nicht ausführbaren Binärformates auszuführen, hier ein Gif-Bild:

user@linux ~$ ls -l ./test.gif -rw-r--r-- 1 matthias users 15568 2002-11-07 15:03 ./test.gif user@linux ~$ test.gif bash: ./test.gif: Keine Berechtigung user@linux ~$ chmod +x test.gif user@linux ~$ ./test.gif bash: ./test.gif: cannot execute binary file

Bei Skripten muss feiner differenziert werden. Welcher Interpreter für ein Skript gestartet wird, ist durch die erste Zeile eines Skriptes hinter dem sogenannten Shebang (amerikanisch "the whole shebang": der ganze Plunder) definiert. Die Bezeichnung "Shebang" ist vermutlich von "shell bang" abgeleitet. Es handelt sich um die Zeichenfolge #!, z.B.

Beispiel

    #! /bin/sh
    #
    kommando1
    kommando2
    ...

In der ersten Zeile findet sich der Shebang nebst Angabe des zu verwendenden Interpreters. Im obigen Fall ist /bin/sh definiert. Es könnten dort auch andere Shells oder Interpreter verschiedener Skriptsprachen wie Perl oder Tcl verwendet werden.

Weshalb wird dies hier überhaupt erläutert? Der Grund ist, dass Skripte auf verschiedene Weisen aufgerufen werden können und es von dieser Aufrufart abhängt, in welcher Weise sich das Ausführrecht auswirkt. Als Beispiel soll das folgende Skript dienen:

user@linux ~$ pwd /home/matthias user@linux ~$ cat testscript.sh #! /bin/sh echo "Hallo!" user@linux ~$ ls -l testscript.sh -rw-r--r-- 1 matthias users 24 2002-11-07 23:04 testscript.sh

Wie zu sehen, referenziert das Skript auf /bin/sh als Interpreter, gibt im Falle einer Ausführung die Zeichenfolge "Hallo!" aus und besitzt derzeit keinerlei Ausführrechte. Trotzdem kann es auf verschiedene Weisen ausgeführt werden:

user@linux ~$ sh testscript.sh Hallo! user@linux ~$ source testscript.sh Hallo! user@linux ~$ . testscript.sh Hallo!

Versucht man jedoch, das Skript namentlich aufzurufen, scheitert dies an der mangelnden Berechtigung. Hier die drei verschiedenen Möglichkeiten, das zu tun:

user@linux ~$ testscript.sh bash: ./testscript.sh: Keine Berechtigung user@linux ~$ ./testscript.sh bash: ./testscript.sh: Keine Berechtigung user@linux ~$ /home/matthias/testscript.sh bash: /home/matthias/testscript.sh: Keine Berechtigung

Zuerst durch simple Angabe des Namens (das . Verzeichnis muss hierfür in PATH aufgeführt sein), dann relativ, dann absolut. In allen drei Fällen fehlt das Ausführrecht.

Der Unterschied kann so erklärt werden: Geben Sie ein Kommando ein, so prüft die Shell, ob für dieses Kommando die Berechtigung zur Ausführung besteht. Dabei stellt jeweils das erste Wort Ihrer Eingabezeile das Kommando dar, die restlichen Worte bilden die Parameter. In den drei Beispielen unter Verwendung von sh, source und . wird also die Berechtigung dieser drei Kommandos geprüft und nicht diejenige des Skriptes selbst. Der Skriptname wird dann nur noch als Parameter an das Kommando übergeben und von diesem entsprechend behandelt. In diesem Fall muss nur noch das Leserecht gesetzt sein, denn das Kommando muss die Datei natürlich zumindest einlesen können:

user@linux ~$ chmod -r testscript.sh user@linux ~$ sh testscript.sh testscript.sh: testscript.sh: Keine Berechtigung

Referenzieren Sie hingegen das Skript in einer der drei genannten Arten direkt unter der Ausnutzung des Shebang-Mechanismus, prüft die Shell das Ausführrecht und verweigert u.U. die Ausführung. Das Leserecht muss freilich auch hier bestehen - Ausführen impliziert für Skripte (im Gegensatz zu Programmdateien) vorheriges Einlesen!

#### 5.3.2 Ausführrecht für Verzeichnisse

Das Ausführrecht für Verzeichnisse bezeichnet das elementare Recht, dieses Verzeichnis zu betreten. Hier das grundlegende Beipiel:

user@linux ~$ chmod -x testdir user@linux ~$ ls -l | grep testdir drw-r--r-- 2 matthias users 48 2002-11-07 23:50 testdir user@linux ~$ cd testdir bash: cd: testdir: Keine Berechtigung user@linux ~$ chmod +x testdir user@linux ~$ cd testdir user@linux ~/testdir$ pwd /home/matthias/testdir

Das "Betreten" eines Verzeichnisses ist jedoch allgemeiner zu verstehen als das bloße Wechseln des current working directory. Es ist vielmehr die grundlegende Voraussetzung für alle weiteren Operationen auf dem Verzeichnis und seinen Inhalten. Lesen von Dateien, Anlegen und Löschen von Dateien und auch Ausführen von Dateien in einem Verzeichnis erfordern ein Ausführrecht auf diesem Verzeichnis. Dies gilt übrigens rekursiv auch für alle Unterverzeichnisse und deren Inhalte.

Auslesen des Verzeichnisses:

user@linux ~$ ls testdir testscript.sh user@linux ~$ chmod -x testdir user@linux ~$ ls testdir ls: testdir/testscript.sh: Keine Berechtigung

Hierbei ist interessant, dass sich die Fehlermeldung nicht auf das Lesen des Verzeichnisses selbst bezieht. Die im Verzeichnis enthaltene Datei testscript.sh wird sogar in der Fehlermeldung genannt und konnte also aus dem Verzeichniskatalog ausgelesen werden. Das ist auch nicht verwunderlich, denn das Leserecht für das Verzeichnis ist ja weiterhin gesetzt. Die Fehlermeldung bezieht sich vielmehr auf den Versuch, Information über die Datei testscript.sh auszulesen. Hierzu müsste auf diese Datei zugegriffen werden. Um auf die Datei eines Verzeichnisses zugreifen zu können, muss jedoch das Aussführrecht für das Verzeichnis gesetzt sein. Da dies nicht der Fall war, wurde ls der Zugriff verweigert.

Lesen einer Datei:

user@linux ~$ chmod +x testdir user@linux ~$ echo "Neue Testdatei." > testdir/lesetest.txt user@linux ~$ cat testdir/lesetest.txt Neue Testdatei. user@linux ~$ chmod -x testdir user@linux ~$ cat testdir/lesetest.txt cat: testdir/lesetest.txt: Keine Berechtigung

Anlegen und Löschen einer Datei:

user@linux ~$ touch testdir/testfile touch: Erzeugen von "testdir/testfile": Keine Berechtigung user@linux ~$ rm testdir/lesetest.txt rm: Aufruf von lstat für "testdir/lesetest.txt" nicht möglich: Keine Berechtigung user@linux ~$ chmod +x testdir user@linux ~$ touch testdir/testfile user@linux ~$ rm testdir/lesetest.txt

Ausführen einer Datei:

user@linux ~$ ls -l testdir/testscript.sh -rwxr-xr-x 1 matthias users 25 2002-11-07 23:56 testdir/testscript.sh user@linux ~$ ./testdir/testscript.sh Hallo! user@linux ~$ chmod -x testdir user@linux ~$ ./testdir/testscript.sh bash: ./testdir/testscript.sh: Keine Berechtigung

Auch für Unterverzeichnisse sind die Einschränkungen wirksam:

user@linux ~$ mkdir testdir/subdir user@linux ~$ touch testdir/subdir/testfile user@linux ~$ ls testdir/subdir testfile user@linux ~$ chmod -x testdir user@linux ~$ ls testdir/subdir ls: testdir/subdir: Keine Berechtigung

Damit soll die ausführliche Behandlung der Dateirechte hier abgeschlossen werden. Wie zu erkennen ist, ergeben sich aus dem an sich einfachen Konzept aus drei Benutzerklassen (user, group, others) und drei Berechtigungsklassen (read, write, execute) durchaus komplexe Zusammenhänge und Möglichkeiten zur Abstufung von Berechtigungen. Die Kombination der verschiedenen Rechte und ihre Anwendung auf unterschiedliche Dateitypen (wobei hier bereits eine Einschränkung auf reguläre Dateien und Verzeichnisse vorgenommen wurde) bietet ein breites Experimentierfeld und ist immer wieder für Überraschungen gut.

Am besten spielen Sie selbst einmal mit den vielfältigen Möglichkeiten, um eine gewisse Intuition im Umgang mit den Rechten zu gewinnen. Für die Zusendung besonders interessanter Beispiele sind die Autoren dankbar und werden sie gerne in dieses Kapitel aufnehmen.

Richten Sie nun - nach einer angemessenen Pause - Ihre Aufmerksamkeit auf die zentralen Benutzerdateien im Rahmen der Benutzerkonzeption.