Linux-Praxisbuch/ Benutzer- und Berechtigungskonzepte
Dieser Text ist den grundlegenden Konzepten des Benutzer- und Berechtigungssystems von Linux gewidmet. Das Thema Benutzerverwaltung baut auf diesen Konzepten auf, wird hier aber nicht explizit behandelt. Vielmehr soll eine Kenntnis der wichtigsten Begriffe und ein Verständnis für das große Ganze vermittelt werden, welches in der Benutzerverwaltung seine Anwendung findet. Den praktischen Aspekten der Benutzerverwaltung ist ein separates Kapitel gewidmet.
Einleitung
[Bearbeiten]Die Nutzung von Informationssystemen ist üblicherweise mit einem Zugangssystem verbunden, welches die Verwendung des Systems auf eine bekannte Benutzergruppe beschränkt, Daten über die registrierten Benutzer speichert und die Verteilung der Ressourcen auf die Benutzer steuert. Häufig ist die Konzeption des Zugangssystems für den einzelnen Benutzer transparent - außer seinem Benutzernamen und einem Passwort benötigt der Benutzer kaum weitere Kenntnisse, um das System in Anspruch zu nehmen. Für die Arbeit mit einem Linux-System sollten Sie sich dennoch einige elementare Kenntnisse über dessen Benutzer- und Berechtigungskonzept aneignen.
Die Notwendigkeit für diese Konzepte ergibt sich für Linux aus seiner Mehrbenutzerfähigkeit. Ein erster wichtiger Aspekt ist der Schutz des Systems vor den Handlungen seiner Benutzer. Weiterhin müssen auch die einen Benutzer vor den Handlungen der anderen geschützt werden. Und schließlich darf bei allem Schutz des Systems und der Benutzer voreinander das Miteinander-Arbeiten nicht allzusehr erschwert werden. Um all dies zu gewährleisten, bedarf es eines feinkörnigen Systems der Einschränkungen und Erlaubnisse. Dieses System ideal an die jeweiligen Gegebenheiten anzupassen, ist die Aufgabe des Systemverwalters. Es bleibt zu hoffen, dass er diese Aufgabe in Absprache mit den Benutzern wahrnimmt.
Dieser Text ist derzeit in fünf Hauptabschnitte gegliedert. Im ersten Abschnitt Was ist ein Benutzer? wird erläutert, was einen Benutzer unter Linux ausmacht. Der zweite Abschnitt Benutzertypen behandelt die Unterschiede zwischen Standardbenutzern, Systembenutzern und dem Superuser root. Abschnitt drei, Benutzerklassen: user, group und others widmet sich den für das Berechtigungskonzept zentralen Benutzerklassen unter Linux. In Abschnitt vier, Berechtigungstypen: Lesen, Schreiben und Ausführen werden die Berechtigungstypen für diese Benutzerklassen im Detail ausgeführt. Abschnitt fünf schließlich beschreibt überblicksweise die für die Benutzerverwaltung zentralen Konfigurationsdateien.
Die Autoren sind sich der Tatsache bewusst, dass damit wesentliche Themen, die in dieses Kapitel gehören, noch nicht abgehandelt wurden.
Was ist ein Benutzer?
[Bearbeiten]Benutzername und Passwort
[Bearbeiten]Ein Benutzerkonto besteht in der Informationstechnik aus einer Benutzername/Passwort-Kombination. Von einer weiteren Verkomplizierung des Zugangssystems, etwa durch Einsatz von Verschlüsselungstechnologien aus Gründen erhöhter Sicherheitsanforderungen, soll in diesem Kapitel nicht die Rede sein.
Erwartungsgemäß melden Sie sich auch bei Linux durch die Angabe Ihres Benutzernamens und des zugehörigen Passwortes an. Mehr muss der Anwender im allgemeinen nicht wissen. Aus Systemsicht sind jedoch noch einige weitere Attribute Ihres Benutzerkontos interessant.
Benutzer-ID (UID) und Gruppen-ID (GID)
[Bearbeiten]Während Sie üblicherweise einfach einen Benutzernamen angeben, um sich auf einen bestimmten Benutzer zu beziehen, verwendet Linux intern lediglich eine Identifikationsnummer, die sogenannte Benutzer-ID (UID für User-ID, engl. user: der Benutzer). Betrachten Sie die (verkürzte) Ausgabe des folgenden Kommandos:
user@linux ~$ id uid=500(matthias)
In Klammern sehen Sie den vertrauten Benutzernamen, hier matthias. Die UID ist 500. Für interne Zwecke findet nahezu ausschließlich die UID Verwendung. Selbst wenn Sie Kommandos absetzen, welche den Benutzernamen als Parameter erwarten, findet zunächst eine Zuordnung des Namens auf die UID statt, bevor die gewünschte Aktion ausgeführt wird. Umgekehrt sollten Sie sich nicht täuschen lassen, wenn Ihnen ein Kommando den Benutzernamen anstelle der UID liefert. Betrachten Sie z.B. die folgende (wiederum etwas komprimierte) Ausgabe:
user@linux ~$ ps -aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 448 64 ? S Jun21 0:07 init [3] root 2 0.0 0.0 0 0 ? SW Jun21 0:00 [keventd] nobody 650 0.0 0.1 5680 716 ? S Jun21 0:00 /usr/sbin/in.identd -e nobody 653 0.0 0.1 5680 716 ? S Jun21 0:01 /usr/sbin/in.identd -e lp 746 0.0 0.1 1944 712 ? S Jun21 0:00 lpd Waiting matthias 15971 0.0 0.2 2528 1188 tty1 S 01:09 0:00 /bin/sh/usr/X11R6/bin/startx matthias 16097 0.0 0.3 2816 1576 pts/1 S 01:09 0:00 /bin/bash
In der ersten Spalte listet ps bereitwillig die vertrauten oder weniger vertrauten Namen diverser Benutzer (root, nobody, lp, matthias) auf. Das System verwaltet allerdings die Prozesse nicht unter den Benutzernamen, sondern ausschließlich unter deren UIDs. ps hat hier eigenständig eine Zuordnung von den UIDs auf die Benutzernamen vorgenommen.
Neben der UID ist jedem Benutzer eine weitere Nummer zugeordnet, die sogenannte Gruppen-ID (GID). Auch diese Nummer liefert das id Kommando (hier die etwas längere, aber immer noch verkürzte Ausgabe):
user@linux ~$ id uid=500(matthias) gid=100(users)
Jeder Prozess trägt UID und GID seines Erzeugers. Wie diese beiden Kennzahlen bei der Ermittlung von Berechtigungen verwendet werden, wird später im Detail erläutert.
Nach der Anmeldung - die Shell
[Bearbeiten]Nach der Anmeldung möchte sich der Benutzer in einer Umgebung wiederfinden, welche ihm das Arbeiten ermöglicht. Erfolgt die Anmeldung nicht über einen Display-Manager, so wird für gewöhnliche Benutzer eine Shell gestartet. Um welche Shell es sich handelt, wird dabei für jeden Benutzer einzeln festgelegt. In der Tat kann man für einzelne Benutzer auch festlegen, dass sie keine Shell erhalten - z.B. wenn man sie temporär vom System aussperren möchte oder wenn für einzelne Benutzer generell keine Shell-Umgebung ermöglicht werden soll. Wie später noch gezeigt wird, kann dies sehr sinnvoll sein und kommt durchaus häufig vor.
Das Heimatverzeichnis
[Bearbeiten]Die Login-Shell startet im sogenannten Heimatverzeichnis des Benutzers. Dieses und alle seine Unterverzeichnisse gehören dem Benutzer. Was genau damit gemeint ist, wird in einigen Augenblicken erläutert. Im Wesentlichen bietet das Heimatverzeichnis seinem Besitzer Platz für die Ablage von Dateien, welche meist oder auschließlich von ihm verwendet werden. Neben den Arbeitsdateien und -verzeichnissen selbst liegen im Heimatverzeichnis noch eine Reihe (meist unsichtbarer) Dateien, welche applikationsspezifische Einstellungen des Benutzers enthalten. Es ist somit der Dreh- und Angelpunkt der Aktivitäten des Benutzers - eine gewohnte, vor anderen Benutzern geschützte Umgebung.
Was ist nun also ein Benutzer?
[Bearbeiten]Benutzername und Passwort, UID, Login-Programm (üblicherweise eine Shell) und Heimatverzeichnis sind es also, die zusammengenommen einen Benutzer auf einem Linux-System ausmachen. All diese Daten werden in einer zentralen Benutzerdatei verwaltet. Bevor diese näher beschrieben wird, folgt eine Einteilung der auf einem Linux-System möglichen Benutzer in Benutzertypen.
Benutzertypen
[Bearbeiten]Hier nochmals die verkürzte Ausgabe eines ps Kommandos als Beispiel:
user@linux ~$ ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 448 64 ? S Jun21 0:07 init [3] root 2 0.0 0.0 0 0 ? SW Jun21 0:00 [keventd] nobody 650 0.0 0.1 5680 716 ? S Jun21 0:00 /usr/sbin/in.identd -e nobody 653 0.0 0.1 5680 716 ? S Jun21 0:01 /usr/sbin/in.identd -e lp 746 0.0 0.1 1944 712 ? S Jun21 0:00 lpd Waiting matthias 15971 0.0 0.2 2528 1188 tty1 S 01:09 0:00 /bin/sh/usr/X11R6/bin/startx matthias 16097 0.0 0.2 2816 1576 pts/1 S 01:09 0:00 /bin/bash
Die Benutzer root, nobody, lp und matthias sind als Inhaber der jeweiligen Prozesse gelistet. Die Autoren versichern Ihnen jedoch, dass zum Zeitpunkt dieses Kommandos lediglich ein einziger Benutzer auf dem System angemeldet war, nämlich der Benutzer matthias. Die Tatsache, dass dennoch einige Prozesse auf dem System unter der Kennung anderer Benutzer laufen, zeigt bereits an, dass es verschiedene Typen von Benutzern geben muss. Gewöhnlichen Benutzern wäre es nämlich unmöglich, ohne vorherige Anmeldung einen Prozess zu starten. Wir unterscheiden daher drei Benutzertypen: Erstens den Systemverwalter oder Superuser root, zweitens alle Standardbenutzer und drittens die Systembenutzer.
root
[Bearbeiten]Der Benutzer root ist mit allen Rechten ausgestattet, die ihm die Administration (bei Unachtsamkeit natürlich auch die Beschädigung!) des Systems erlauben. Diesem auch als Superuser bezeichneten Benutzer ist immer die UID 0 zugeordnet:
root@linux ~# id uid=0(root) gid=0(root) Gruppen=0(root) [...]
Dieses Benutzerkonto dient ausschließlich Eingriffen in die Konfiguration des Systems und sollte nur dann verwendet werden, wenn kein anderer Benutzer die für eine Aufgabe notwendigen Rechte innehat. Der unter Einsteigern beliebteste Fehler ist es, sich zunächst ausschließlich als root anzumelden. Da nach der Systeminstallation ohnehin noch häufig administrative Aufgaben erledigt werden müssen, wird es als lästig empfunden, permanent zwischen einem Benutzer- und dem Superuser-Konto hin- und herzuwechseln. Die Bequemlichkeit wird oft mit einer Beschädigung des Systems bezahlt.
Es gibt Prozesse, die immer unter der Kennung des Superusers laufen und auch laufen müssen. Das einfachste Beispiel ist der Prozess init, der auch in der obigen Ausgabe erscheint. init ist der erste Prozess, der nach dem Booten des Kernels die Kontrolle übernimmt und wird daher auch als "Vater aller Prozesse" bezeichnet. Dies drückt sich in der Prozess-ID 1 aus. Da zum Zeitpunkt des Startens von init freilich noch kein Benutzer auf dem System angemeldet sein kann, andererseits aber jedem Prozess eine gültige Benutzerkennung zugeordnet sein muss, und da init des weiteren zur Erledigung seiner Aufgaben mit weitreichenden Rechten ausgestattet sein muss, läuft init unter der Kennung des Superusers root. Dass dies nicht nur für init gilt, zeigt das folgende Kommando:
root@linux ~# ps aux | grep root root 1 0.0 0.0 448 76 ? S Oct25 0:07 init [...] root 4 0.0 0.0 0 0 ? SW Oct25 0:01 [keventd] [...] root 602 0.0 0.1 1356 552 ? S Oct25 0:01 /sbin/syslogd [...] root 1651 0.0 0.6 4856 3232 ? S Oct25 0:08 /usr/sbin/cupsd [...] root 2063 0.0 0.0 1260 4 tty1 S Oct25 0:00 /sbin/mingetty --noclear tty1 [...]
Diese nach Prozessnummern geordnete, verkürzte Liste zeigt im oberen Bereich zunächst den Vater aller Prozesse init. Danach folgen kernelnahe Prozesse, welche bereits früh während des Bootvorganges gestartet werden. Später kommen einige Dienst- und Serverprozesse hinzu, darunter der Log-Daemon syslogd, der Druckdienst cupsd sowie einige Terminalprozesse (mingetty's), welche das Einloggen auf den verschiedenen Konsolen ermöglichen. All diese Prozesse wurden nicht etwa von einem eingeloggten Benutzer root gestartet, sondern automatisch beim Hochfahren des Systems - allerdings unter der Kennung von root, d. h. mit UID 0.
Systembenutzer
[Bearbeiten]Je nach System kann eine Vielzahl von Prozessen und Diensten erwünscht sein, die bereits beim Hochfahren des Systems verfügbar sein sollen. Nicht jeder dieser Prozesse benötigt jedoch die volle Rechteausstattung des Superusers. Man möchte natürlich so wenige Prozesse wie nur möglich unter einer root Kennung starten, da die weitreichenden Rechte solcher Prozesse unnötige Möglichkeiten für Missbrauch und Beschädigung des Systems liefern.
Ein Systembenutzerkonto ist in diesem Sinne ein Benutzerkonto, das jedoch (nahezu) ausschließlich zur Ausführung von Programmen unter einer speziellen Benutzerkennung verwendet wird. Kein menschlicher Benutzer meldet sich normalerweise unter einem solchen Konto an. Die oben bereits gezeigte Ausgabe eines ps Kommandos zeigt zwei häufige Beispiele: Der Drucker-Daemon lpd wurde unter der Benutzerkennung lp gestartet. Zwei Prozesse werden unter der Kennung des Benutzers nobody gelistet. nobody wird generell dann von Prozessen als Benutzerkennung verwendet, wenn nur ein Minimum an Rechten vergeben werden soll. Da nobody (laut Konvention, aber keineswegs notwendigerweise) keiner Gruppe angehört, wird er gewöhnlich der Benutzerklasse others angehören und somit die geringstmöglichen Rechte besitzen. Mehr zu Benutzerklassen folgt unten.
Ein Blick in die zentrale Benutzerdatei (Details zu dieser Datei folgen später) zeigt, dass vielen Systembenutzern explizit keine Shell zugeordnet wird:
root@linux ~# cat /etc/passwd | grep false firewall:x:41:31:Firewall account:/var/lib/firewall:/bin/false postfix:x:51:51:Postfix daemon:/var/spool/postfix:/bin/false mysql:x:60:2:MySQL database admin:/var/lib/mysql:/bin/false dpbox:x:61:56:DpBox account:/var/spool/dpbox:/bin/false zope:x:64:2:Zope daemon:/var/lib/zope:/bin/false vscan:x:65:65534:Vscan account:/var/spool/vscan:/bin/false wnn:x:66:100:Wnn system account:/var/lib/wnn:/bin/false pop:x:67:100:POP admin:/var/lib/pop:/bin/false perforce:x:68:60:Perfoce admin:/var/lib/perforce:/bin/false
Das Programm /bin/false beendet sich ohne weitere Arbeit selbst, sodass ein gewöhnlicher Login als einer der aufgeführten Benutzer nicht zu einer Shellsession führen kann. Prozesse unter dieser Kennung werden somit nicht von einer Benutzershell gestartet, sondern über andere, systemeigene Mechanismen (beispielsweise über Startskripte während des Bootens).
Es soll jedoch nochmals ausdrücklich erwähnt werden, dass die Unterscheidung zwischen Systembenutzern und Standardbenutzern willkürlich ist und nicht durch das Linux-Rechtesystem selbst festgelegt wird. Es hilft jedoch beim Verständnis diverser Rechtekonzepte, wenn man sich der Tatsache bewusst ist, dass es zahlreiche Benutzerkonten gibt, welche ausschließlich im Zusammenhang mit bestimmten Diensten verwendet werden.
Standardbenutzer
[Bearbeiten]Dies ist das normale Benutzerkonto, unter welchem jeder üblicherweise arbeiten sollte.
Benutzerklassen: user, group und others
[Bearbeiten]Aus der Sicht des Systems existieren drei Benutzerklassen, wenn entschieden werden soll, ob die Berechtigung für einen Dateizugriff existiert oder nicht. Soll beispielsweise eine Datei gelöscht werden, so muss das System ermitteln, ob der Benutzer, welcher die Datei löschen möchte, das erforderliche Recht besitzt:
user@linux ~$ rm testdatei rm: Entfernen (unlink) von "testdatei" nicht möglich: Keine Berechtigung
In diesem Fall wurde dem rm Kommando der beabsichtigte löschende Zugriff auf die Datei verwehrt - der ausführende Benutzer hatte nicht das Recht, die Datei zu löschen. Um diese Entscheidung zu treffen, verwendet das System das Konzept der Benutzerklassen. Drei Benutzerklassen werden unterschieden: user, group und others. Jede dieser Benutzerklassen ist wiederum in ein Lese-, Schreib- und Ausführrecht unterteilt. Diese werden im Folgenden als Berechtigungsklassen bezeichnet. Somit ergibt sich folgende Körnung für die einfachen Zugriffsrechte einer Datei:
user-read Leserecht für Dateieigentümer user-write Schreibrecht für Dateieigentümer user-execute Ausführrecht für Dateieigentümer group-read Leserecht für Gruppe des Dateieigentümers group-write Schreibrecht für Gruppe des Dateieigentümers group-execute Ausführrecht für Gruppe des Dateieigentümers other-read Leserecht für alle anderen Benutzer other-write Schreibrecht für alle anderen Benutzer other-execute Ausführrecht für alle anderen Benutzer
Tabelle 1: Einfache Zugriffsrechte für Dateien.
Benutzerklassen sind also eng mit der Eigentümerschaft von Dateien verbunden. Jede Datei und jedes Verzeichnis ist sowohl einem Benutzer (einer UID) als auch einer Gruppe (einer GID) zugeordnet. UID und GID gehören zur elementaren Verwaltungsinformation von Dateien und Verzeichnissen und werden in der sogenannten Inode gespeichert.
Beim Zugriff auf eine Datei werden nun UID und GID des zugreifenden Prozesses mit UID und GID der Datei verglichen. Ist other-read gesetzt, darf jeder Benutzer lesend zugreifen und ein weiterer Vergleich erübrigt sich. Ist lediglich group-read gesetzt, muss der Zugreifende mindestens der Gruppe des Dateieigentümers angehören, d.h. eine identische GID aufweisen. Ist ausschließlich user-read gesetzt, so darf nur der Eigentümer selbst die Datei lesen. root ist von dieser Einschränkung freilich ausgenommen. ("Ich bin root, ich darf das!"). Von sehr speziellen Ausnahmen abgesehen, die sich außerhalb der hier besprochenen Rechteklassen bewegen, ist root in seinen Aktionen in keinerlei Weise eingeschränkt.
| User | Groups | Others | Befehl |
|---|---|---|---|
| r-- | r-- | r-- | Lesen |
| rw- | rw- | rw- | (Lesen und )Schreiben |
| r-x | r-x | r-x | (Lesen und) Ausführen |
| rwx | rwx | rwx | Lesen, Schreiben und Ausführen |
Tabelle um Chmod Befehl zu interpretieren
| User | Groups | Others | Befehl |
|---|---|---|---|
| 4 | 4 | 4 | Lesen |
| 6 | 6 | 6 | (Lesen und) Schreiben |
| 5 | 5 | 5 | (Lesen und) Ausführen |
| 7 | 7 | 7 | Lesen, Schreiben und Ausführen |
Gleiche Tabellen in Zahlen
Die Zahlen in der unteren Tabelle ergeben sich aus der Interpretation der gesetzten Rechte als dreistellige Binärzahlen. Zum besseren Verständnis benennen wir die drei Stellen der Binärzahl entsprechend der zugehörigen Rechte r (=read), w (=write) und x (=execute). Je nachdem ob die Datei durch einen Benutzer bzw. eine Gruppe von Benutzern lesbar, schreibbar oder ausführbar sein soll, setzen wir für die jeweilige Stelle eine 1 (=ja) oder eine 0 (=nein) ein. Aus dem reinen Lesezugriffsrecht "r--" wird dann die Binärzahl "100" die der dezimalen "4" entspricht. Ein reiner Schreibzugriff der Form "-w-" ist in der Regel allerdings wenig sinnvoll, weil wir den Inhalt einer Datei zwar verändern können, uns aber der Inhalt der Datei verschlossen bleibt.
Berechtigungsklassen: Lesen, Schreiben und Ausführen
[Bearbeiten]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 - ein 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 ihrer 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.
Lesen
[Bearbeiten]Leserecht für Dateien
[Bearbeiten]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.
Leserecht für Verzeichnisse
[Bearbeiten]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 testfile 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.
Schreiben
[Bearbeiten]Schreibrecht für Dateien
[Bearbeiten]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.
Schreibrecht für Verzeichnisse
[Bearbeiten]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
Ausführen
[Bearbeiten]Ausführrecht für Dateien
[Bearbeiten]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!
Ausführrecht für Verzeichnisse
[Bearbeiten]Das Ausführrecht für Verzeichnisse bezeichnet das elementare Recht, dieses Verzeichnis zu betreten. Hier das grundlegende Beispiel:
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.
Die zentralen Benutzerdateien
[Bearbeiten]Um das Kapitel abzurunden und Ihnen einen Einblick in die Registratur von Benutzern unter Linux zu geben, werden im Folgenden die zentralen Benutzerdateien beschrieben, welche notwendige Information über Benutzernamen, Passwörter, Gruppenzugehörigkeiten und andere Benutzerattribute enthalten. Den Abschluss bildet der Verweis auf ein System zur zentralen Benutzerverwaltung in Netzwerken, das NIS (Network Information System).
Die Dateien zur Benutzerverwaltung finden Sie unter Linux im Verzeichnis /etc. Es handelt sich dabei um die Dateien /etc/passwd, /etc/shadow und /etc/group.
An dieser Stelle sei nochmals darauf hingewiesen, dass die meisten Linux-Distributionen komfortable Werkzeuge zur Benutzerverwaltung mitliefern und es auch eine Reihe von Befehlen gibt, die für die Benutzerverwaltung verwendet werden können. Diese werden jedoch nicht hier, sondern in dem Kapitel Benutzerverwaltung erläutert. Im Folgenden soll Ihnen lediglich grundlegendes Wissen über den Aufbau, Inhalt und die Funktionen der Dateien erläutert werden, die für die Benutzerverwaltung unter Linux von Bedeutung sind.
Die Datei /etc/passwd
[Bearbeiten]Die Datei /etc/passwd ist die zentrale Benutzerdatenbank.
Mit cat /etc/passwd können Sie einen Blick in diese zentrale Benutzerdatei werfen. Hier werden alle Benutzer des Systems aufgelistet. Zu beachten ist, dass alle Benutzertypen eingetragen sind, also sowohl der Superuser root als auch die Standard- und Systembenutzer.
Ein Benutzerkonto in der Datei /etc/passwd hat generell folgende Syntax:
Benutzername : Passwort : UID : GID : Info : Heimatverzeichnis : Shell
Benutzername Dies ist der Benutzername in druckbaren Zeichen, meistens in Kleinbuchstaben.
Passwort Hier steht verschlüsselt das Passwort des Benutzers (bei alten Systemen).
Meist finden Sie dort ein x. Dies bedeutet, dass das Passwort verschlüsselt
in der Datei /etc/shadow steht. Es ist auch möglich, den Eintrag leer zu lassen.
Dann erfolgt die Anmeldung ohne Passwortabfrage (in der Datei /etc/shadow muss
dann an Stelle des verschlüsselten Passwortes ein * stehen).
UID Die Benutzer-ID des Benutzers. Die Zahl hier sollte größer als 100 sein, weil
die Zahlen unter 100 für Systembenutzer vorgesehen sind. Weiterhin muss die
Zahl aus technischen Gründen kleiner als 64000 sein.
GID Die Gruppen-ID des Benutzers. Auch hier muss die Zahl wie bei der UID kleiner als
64000 sein.
Info Hier kann weitere Information vermerkt werden, wie z.B. der vollständige Name des
Benutzers und persönliche Angaben (Telefonnummer, Abteilung, Gruppenzugehörigkeit u.ä.).
Heimatverzeichnis Das Heimatverzeichnis des Benutzers bzw. das Startverzeichnis nach dem Login.
Shell Die Shell, die nach der Anmeldung gestartet werden soll. Bleibt dieses Feld frei,
dann wird die Standardshell /bin/sh gestartet.
Tabelle 2: Die Felder der Datei /etc/passwd
Hier ein Beispiel für einen Systembenutzer:
uucp:x:10:14:Unix-to-Unix CoPy system:/etc/uucp:/bin/bash
Der Benutzer heißt uucp, das Passwort ist in der Datei /etc/shadow gespeichert (x), die UID ist 10, die GID 14, als erläuternde Bezeichnung trägt der Benutzer den Namen "Unix-to-Unix CoPy system", das Startverzeichnis nach der Anmeldung ist /etc/uucp, und die vorgeschlagene Shell ist die bash.
Die Datei /etc/shadow
[Bearbeiten]Bei früheren Versionen von Linux speicherte man die Passwörter direkt in die passwd-Datei. Allerdings war es durch einen sogenannten Wörterbuchangriff, beispielsweise mit Hilfe des Programmes crypt möglich, diese Passwörter in vielen Fällen zu entschlüsseln und auszulesen. Deshalb hat man die Datei /etc/shadow eingeführt, in der die Angaben über die Passwörter durch ein spezielles System besser geschützt werden.
Der Eintrag in diese Datei erfolgt nach einem ähnlichen Schema, wie in der Datei /etc/passwd:
Benutzername : Passwort : DOC : MinD : MaxD : Warn : Exp : Dis : Res
Benutzername Dies ist der Benutzername in druckbaren Zeichen, meistens in Kleinbuchstaben.
Passwort Hier steht verschlüsselt das Passwort des Benutzers. Wenn hier ein * oder !
steht, dann bedeutet dies, dass kein Passwort vorhanden bzw. eingetragen ist.
DOC Day of last change: der Tag, an dem das Passwort zuletzt geändert wurde.
Besonderheit hier: Der Tag wird als Integer-Zahl in Tagen seit dem 1.1.1970 angegeben.
MinD Minimale Anzahl der Tage, die das Passwort gültig ist.
MaxD Maximale Anzahl der Tage, die das Passwort gültig ist.
Warn Die Anzahl der Tage vor Ablauf der Lebensdauer, ab der vor dem Verfall des Passwortes
zu warnen ist.
Exp Hier wird festgelegt, wieviele Tage das Passwort trotz Ablauf der MaxD noch gültig ist.
Dis Bis zu diesem Tag (auch hier wird ab dem 1.1.1970 gezählt) ist das Benutzerkonto gesperrt
Res Reserve, dieses Feld hat momentan keine Bedeutung.
Tabelle 3: Die Felder der Datei /etc/shadow
Es folgt wieder ein Beispiel:
selflinux:/heSIGnYDr6MI:11995:1:99999:14:::
Der Benutzer heißt selflinux, das Passwort lautet verschlüsselt "/heSIGnYDr6MI". Es wurde zuletzt geändert, als 11995 Tage seit dem 1.1.1970 vergangen waren. Das Passwort ist minimal einen Tag gültig, maximal 99999 Tage (was man als immer deuten kann - 99999 Tage sind ca. 274 Jahre). Es soll ab 14 Tage vor Ablauf des Passwortes gewarnt werden. Die anderen Werte sind vom Administrator nicht definiert und bleiben daher leer.
Die Datei /etc/group
[Bearbeiten]In dieser Datei finden Sie die Benutzergruppen und ihre Mitglieder. In der Datei /etc/passwd wird mit der GID eigentlich schon eine Standardgruppe für den Benutzer festgelegt. In der /etc/group können Sie weitere Gruppenzugehörigkeiten definieren. Das hat in der Praxis vor allem in Netzwerken eine große Bedeutung, weil Sie so in der Lage sind, z.B. Gruppen für Projekte oder Verwaltungseinheiten zu bilden. Für diese Gruppen kann man dann entsprechend die Zugriffsrechte einstellen. Dies hat dann wiederum den Vorteil, dass man die Daten gegen eine unbefugte Benutzung absichern kann.
Der Eintrag einer Gruppe in die Datei sieht so aus:
Gruppenname : Passwort : GID : Benutzernamen (Mitgliederliste)
Gruppenname Der Name der Gruppe in druckbare Zeichen, auch hier meistens Kleinbuchstaben.
Passwort Die Besonderheit hier ist folgende: Wenn das Passwort eingerichtet ist, können
auch Nichtmitglieder der Gruppe Zugang zu den Daten der Gruppe erhalten, wenn
ihnen das Passwort bekannt ist. Ein x sagt hier aus, das das Passwort in
/etc/shadow abgelegt ist. Der Eintrag kann auch entfallen, dann ist die Gruppe
nicht durch ein Passwort geschützt. In diesem Fall kann jedoch auch kein Benutzer
in die Gruppe wechseln, der nicht in diese Gruppe eingetragen ist.
GID Gruppen-ID der Gruppe
Benutzernamen hier werden die Mitglieder der Gruppe eingetragen. Diese sind durch ein einfaches
Komma getrennt.
Tabelle 4: Die Felder der Datei /etc/group
Für einen korrekten Eintrag in die /etc/group reicht eigentlich der Gruppenname und die GID aus. Damit ist die Gruppe dem System bekannt gemacht. Die Felder für das Passwort und die Benutzernamen können frei bleiben.
Wenn allerdings ein Benutzer in mehr als einer Gruppe (außer in seiner Standardgruppe, welche in der /etc/passwd fesgelegt wurde) Mitglied sein soll, so muss er in die entsprechenden Gruppen eingetragen werden. Wollen Sie, dass mehrere Mitglieder in einer Gruppe zusammenarbeiten und diese Gruppe ist nicht die Standardgruppe dieser Mitglieder, dann müssen Sie ebenfalls jedes dieser Mitglieder in die gewünschte Gruppe eintragen. Nochmal zur besseren Veranschaulichung mit anderen Worten. Soll der Benutzer nur in seiner Standardgruppe bleiben, ist kein Eintrag in die /etc/group notwendig. Hier reicht der Eintrag in die /etc/passwd völlig aus, weil dort die Standardgruppe schon mit angegeben wird. Nur wenn der Benutzer in weiteren bzw. mehreren Gruppen Mitglied sein soll, muss dies in die /etc/group-Datei eingetragen werden. Für Passwörter gilt das oben in der Tabelle Gesagte.
Hier sehen Sie ein Beispiel für einen Eintrag:
dialout:x:16:root,tatiana,steuer,selflinux
Sie sehen eine Gruppe mit der GID "16" und den Namen dialout. (Zur Information: dialout erlaubt es normalen Benutzern einen ppp-Verbindungsaufbau zu starten, normalerweise hat nur root dieses Recht). Das x bedeutet hier, dass das Passwort in /etc/shadow abgelegt ist. Da in /etc/shadow hier bei Passwort ein * steht, ist also kein Passwort für die Gruppe vorhanden (Das bedeutet wiederum, dass nur die eingetragenen Mitglieder Zugang zu dieser Gruppe haben). Mitglieder der Gruppe sind: root, tatiana, steuer, selflinux.
Das Verzeichnis /etc/skel
[Bearbeiten]Dieses Verzeichnis hat mit der Benutzerverwaltung im engeren Sinn nichts zu tun. Es soll hier aber trotzdem erwähnt werden, denn in diesem Verzeichnis haben Sie die Möglichkeit, die "Erstausstattung" an Konfigurationsdateien, die ein neuer Benutzer erhalten soll, festzulegen. Jedes Mal, wenn Sie einen neuen Benutzer einrichten, können Sie durch einfaches Kopieren des Verzeichnisses /etc/skel dem neuen Nutzer eine vorgefertigte, einheitliche Umgebung bereit stellen.
In der Praxis wird von dem /etc/skel-Verzeichnis sehr oft Gebrauch gemacht, denn sie müssen dieses Verzeichnis nur einmal anlegen und können dann eine große Anzahl von Benutzern auf einfache Weise einrichten. Bei den meisten Linux-Distributionen wird dieses Verzeichnis schon standardmäßig angelegt und kann dann nach den eigenen Wünschen verändert werden.
Network Information Service (NIS)
[Bearbeiten]Wenn mehrere Linux- und Unix-Systeme in einem Netzwerk auf gemeinsame Ressourcen zurückgreifen wollen, dann muss sichergestellt sein, dass die Benutzer- und Gruppenkennungen aller Rechner in diesem Netzwerk miteinander harmonieren und es zu keinen Konflikten kommt. Das ist die Aufgabe des Network Information Service (NIS).
Sie können NIS als Datenbanksystem verstehen, das Zugriff auf die Dateien /etc/passwd, /etc/shadow und /etc/group in dem gesamten angeschlossenen Netzwerk ermöglicht.