Treffen Einfalt und Gründlichkeit zusammen, entsteht Verwaltung._$ret_-- Oliver Hassencamp

8 Benutzerverwaltung

Nach den Konzepten aus dem Kernel- und dem Userspace sowie einigen umfassenden Kapiteln zum wichtigsten Unix-Werkzeug – der Shell – wollen wir uns in den folgenden Kapiteln mit der Systemadministration befassen. Wie gewohnt werden wir dabei ins Detail gehen und Linux und BSD »pur« und ohne distributionsspezifischen Overhead betrachten.

Als erstem und wichtigstem Thema wollen wir uns dabei der Benutzerverwaltung widmen. Dass Unix schon in den Anfangstagen mehrbenutzerfähig wurde und dass sich dieses Konzept somit durchgängig und vor allem konsistent in den Betriebssystemkern integriert, wissen Sie spätestens seit dem ersten Kapitel. Im Folgenden werden wir wieder mehr von »Unix« als von »Linux« und »BSD« reden, da die Benutzerverwaltung eine der vielen Gemeinsamkeiten dieser Systeme ist.

8.1 Benutzer in Unix 

Benutzer und Prozesse

Betrachten wir also zuerst die Implementierung der Benutzer in Unix. Wenn Sie an das Kernel-Kapitel denken, werden Sie sich zwar an Prozesse, Rechte und Benutzer erinnern, aber eine konkrete Datenstruktur für Benutzer beziehungsweise deren Rechte werden Sie sich nicht ins Gedächtnis rufen können: Sie existiert nämlich nicht.

8.1.1 UID und GID 

Stattdessen sind die Benutzer- (»UID«, user id) und Gruppenidentitäten (»GID«, group id)

Verschiedene IDs

und als solche im Prozesskontrollblock hinterlegt. Jedoch muss hier bereits eingeschränkt werden: Es gibt nicht die UserID. Stattdessen unterscheidet man zwischen der realen UID (RUID), der effektiven UID (EUID) und der saved UID (SUID). Linux kennt dazu noch eine Benutzeridentität für den Zugriff auf Dateisysteme: die filesystem UID (FSUID):

• RUID und RGID

• Die reale Benutzer- und Gruppenidentität entspricht dabei der Identität des Benutzers, der diesen Prozess gestartet hat.

• EUID und EGID

• Die effektive Identität wird für Rechteprüfungen benutzt. Der Administrator kann diese ID bei bestimmten Programmen durch das Setzen des SetUID-Flags in der Rechtemaske verändern.

• So können normale Benutzer mit erweiterten Rechten ausgestattete vertrauenswürdige Programme für bestimmte Aufgaben wie das Setzen eines neuen Passworts benutzen.

• SUID und SGID

• Die gesicherte Identität ist ein Feature, das durch den POSIX-Standard in die Kernel von Linux und BSD eingeführt wurde. Beim Verändern der EUID wird dieser neue Wert, sofern er sich von der RUID unterscheidet, in der SUID abgelegt. Später kann dann dieser Wert wieder als EUID gesetzt werden.

• Das hat den Vorteil, dass mit speziellen erweiterten Rechten ausgestattete Programme diese nur nutzen brauchen, wenn sie es müssen. Setzt nämlich ein Programm eine von der RUID unterschiedliche Benutzeridentität als EUID, so wird dieser Wert in der SUID gespeichert. Später kann dann die EUID wieder zur RUID zurückgesetzt werden, was den Inhalt der SUID nicht verändert. Sollten die erweiterten Rechte dann noch einmal gebraucht werden, so kann man die

• EUID wieder auf den in der SUID gespeicherten privilegierten Wert setzen.

• FSUID und FSGID

• Unter Linux ist die FSUID die Identität für den Zugriff auf das Dateisystem und normalerweise mit der EUID identisch - so wird auch die FSUID verändert, wenn die EUID neu gesetzt wird. Jedoch hat man unter Linux über den Syscall setfsuid() die Möglichkeit, diese Identität gesondert zu verändern.

Beschränkung auf das Dateisystem

• So können dann zum Beispiel Programme wie ein NFS-Server <NFS ist das Network Filesystem. Andere Unix-Systeme können die von einem NFS-Server freigegebenen Verzeichnisse wie lokale Datenträger mounten.> ihre Rechte nur auf den Dateizugriff beschränken und so eine zusätzliche Sicherheitsstufe gewährleisten.

Zu erwähnen bleibt noch die Besonderheit der UID »0«: Sie kennzeichnet den Administrator root, der generell uneingeschränkte Rechte hat. Da man mit einer solchen Macht allerdings auch versehentlich viel Schaden anrichten kann, wird empfohlen, nicht direkt als root zu arbeiten. Stattdessen sollten die Hilfsprogramme su und sudo genutzt werden, die wir später noch ausführlich erläutern werden.

Außerdem kann ein Benutzer natürlich in mehreren Gruppen Mitglied sein. Nähere Auskunft über die Gruppenzugehörigkeit erhalten Sie mit dem groups-Befehl:

jploetner@workstation:~$ groups 
jploetner cdrom sudo audio video games users ssh

Listing 8.1    Die Gruppenzugehörigkeit

Login und Rechte

Interessant ist auch der Zeitpunkt, zu dem diese Rechte gesetzt werden: beim Login. Stellen Sie sich dazu folgende Situation vor: Um einem User erweiterte Zugriffsrechte zu gewähren, wird er vom Administrator zu einer weiteren Gruppe hinzugefügt. Ist der Benutzer zu diesem Zeitpunkt aber eingeloggt, so bleibt die Änderung erst einmal unbemerkt.

Schließlich sind die aktuell gültigen Rechte eine Eigenschaft der Shell und haben nichts mit den vom Administrator veränderten Konfigurationsdateien zu tun. Diese werden erst beim nächsten Login ausgelesen, wodurch die erweiterten Rechte erst dann aktiv werden.

8.1.2 Die /etc/passwd 

Die Information über Benutzer und dabei auch die Abbildung von Benutzernamen auf die UID ist in einer besonderen Datei, der /etc/passwd, abgelegt. Eine typische Zeile sieht dabei wie folgt aus:

jploetner:x:500:500:Johannes:/home/jploetner:/bin/bash

Listing 8.2    Eine Zeile der /etc/passwd

Die einzelnen durch Doppelpunkte getrennten Felder identifizieren dabei jeweils unterschiedliche Eigenschaften eines Benutzerkontos:

• Der Benutzername

• Der meist aus Kleinbuchstaben und manchmal auch aus Zahlen bestehende Benutzername wird zum Beispiel zum Einloggen oder bei anderen Repräsentationen der UID im System benötigt. Ein Benutzername muss dabei mit einem Buchstaben beginnen – den Grund hierfür werden wir später noch erklären.

• Das Passwort

• Im nächsten Feld sollte eigentlich das verschlüsselte Passwort stehen. Warum in unserem Fall jedoch ein »x«

• an dieser Stelle steht, werden wir im nächsten Abschnitt erklären.

• Die UID

Systeminterne Repräsentation

• Im nächsten Feld wird die UID angegeben. Diese Zahl wird nun im Prozesskontrollblock und auch innerhalb des Dateisystems für die Repräsentation der Benutzeridentität benutzt. Der Benutzername ist also für den Benutzer, die ID für das System. Natürlich sollte kein Benutzername auf eine bereits vergebene ID abgebildet werden.

• Die GID

• Im nächsten Fall wird die primäre Gruppe des Benutzers angegeben, also die Gruppe, zu der der Benutzer bei seiner Erstellung hinzugefügt wurde. In vielen Linux-Distributionen ist das eine für diese Benutzer eigens angelegte Gruppe – das hat den Sinn, dass die Benutzer wirklich voneinander getrennt und damit voreinander geschützt sind. In unserem Fall ist die GID sogar dieselbe Nummer wie die UID, ein Zufall, der nicht unbedingt gegeben sein muss.

• Das Infofeld

• Das nächste Feld ist für Informationszwecke frei nutzbar. In den meisten Fällen findet man hier den wirklichen Namen des Benutzers, theoretisch können aber auch Adressen, Telefonnummern oder Büronummern abgelegt werden.

• Das Heimatverzeichnis

• Als Nächstes folgt das Heimatverzeichnis des Benutzers. Auf dieses Verzeichnis sollte der Benutzer Schreibrechte haben, da sonst unter Umständen das Login fehlschlagen kann. <Diese Anspielung bezieht sich vor allem auf die grafischen Oberflächen wie beispielsweise KDE, die beim Start unter anderem temporäre Dateien ablegen wollen.>

• Die Shell

• Als letztes, aber nicht als unwichtigstes Feld kann der Benutzer hier seine Lieblings-Shell angeben. Wie Sie spätestens seit Kapitel 3 wissen, gibt es mehr als eine Shell.

Natürlich muss man als Administrator diese Datei nicht von Hand bearbeiten. Wie man komfortabel Benutzer anlegen und auch wieder löschen kann, werden wir bald behandeln.

8.1.3 Die Shadowsuite 

Die Passwörter schützen

Vorher jedoch wollen wir uns mit der Speicherung der Passwörter in modernen Unix-Systemen beschäftigen. Aus verschiedensten Gründen muss nämlich die /etc/passwd für alle Benutzer lesbar sein. Das würde nun bedeuten, dass jeder Benutzer die verschlüsselten Passwörter auslesen könnte. Theoretisch könnte man diese dann auf einem beliebigen

(Hochleistungs-)Rechner zu knacken versuchen.

Es bietet sich also an, die Metainformationen über Benutzer und die gespeicherten Passwörter in verschiedene Dateien aufzuteilen. Und so sind die Metadaten in der /etc/passwd und die Passwörter unter Linux in der

/etc/shadow gespeichert. Die shadow-Datei ist dabei nur vom Administrator root lesbar. In der Datei selbst steht nur die Kombination von Benutzername und Passwort:

jploetner:$1$QJgtvoES$Ji/rS...Zrbq1:12201:0:99999:7:::

Listing 8.3    Eine Zeile der /etc/shadow

Das zweite Feld dieser Datei ist dabei das verschlüsselte Passwort, dem nun bestimmte Felder zur Gültigkeit des Passworts folgen. Fassen wir nun noch einmal alle Felder der Datei zusammen:

• Der Benutzername

• Der Benutzername muss natürlich mit dem Benutzernamen in der Datei /etc/passwd übereinstimmen.

• Verschlüsseltes Passwort

• Im nächsten Feld steht das verschlüsselte Passwort, das wir ja statt in der für alle Benutzer lesbaren

• /etc/passwd in der nur für root lesbaren Datei /etc/shadow speichern wollen.

• Letzte Änderung

• In diesem Feld steht der Zeitpunkt der letzten Passwortänderung. Er wird als Anzahl der Tage seit dem 1. Januar 1970 angegeben.

• Minimale Gültigkeitsdauer

• Im nächsten Feld steht die minimale Gültigkeitsdauer eines Passwortes. Mit anderen Worten kann das Passwort frühestens nach Ablauf der hier angegebenen Anzahl von Tagen geändert werden. <Dieser Wert ist eigentlich fast immer auf null gesetzt.>

• Maximale Gültigkeitsdauer

Regelmäßige Änderungen

• Hier steht die maximale Gültigkeitsdauer des Passworts. Sie wird wieder in Tagen angegeben. Der Benutzer muss vor Ablauf dieser Frist sein Passwort ändern.

• Vorwarnzeit

• Damit der Benutzer dafür genug Zeit hat, kann man im nächsten Feld eine Vorwarnzeit (wieder in Tagen) angeben. In dieser Zeitspanne vor Ablauf des Passworts wird der Benutzer darauf hingewiesen, sein Passwort zu ändern.

• Inaktivität

• Die Anzahl der Tage nach Ablauf der Gültigkeit eines Passworts, nach denen der Account inaktiv gesetzt wird.

• Accountende

• Das absolute Ende des Accounts: Hier gibt man das Datum, wann der Account deaktiviert werden soll, wieder in Form der Anzahl der Tage seit dem 1. Januar 1970 an.

• Kennzeichen

• Dieses Feld ist für spätere Erweiterungen reserviert und sollte freigelassen werden.

Natürlich reicht das Anlegen einer neuen Datei wie der /etc/shadow allein nicht aus, schließlich sollte ihre Funktionalität auch von den entsprechenden Programmen unterstützt werden. Die Sammlung entsprechend angepasster Programme nennt man dabei die Shadowsuite.

Ihr Kommentar