Die Einrichtung neuer Accounts auf einem Unix-System geschieht weitgehend automatisch, oft mit Hilfe grafischer Oberflächen. Unter der Haube arbeiten dabei einige Mechanismen, die dem neuen User eine komfortable Umgebung bereitstellen. Dieser Workshop zeigt, worauf Admins achten sollten.

Bei modernen Linux-Distributionen genügen wenige Klicks, um einen neuen Benutzer anzulegen. Abbildung 1 zeigt als Beispiel Suse. Unter »Details« passen Admins nach Bedarf weitere Parameter an. Derartige grafische Frontends benutzen Kommandozeilenprogramme wie »adduser« oder »useradd«, die den Großteil der Arbeit erledigen. Distributoren speichern in ihren Frontends meist sinnvolle und gängige Voreinstellungen vieler Parameter.

Für Administratoren ist es gleichwohl wichtig zu wissen, was genau passiert, wenn sie einen neuen Benutzer anlegen. Denn die Automatik lässt sich sehr genau an spezielle Bedürfnisse anpassen. Beim Erstellen von Accounts müssen etwa diverse Datenbanken Basisinformationen über den neuen Benutzer erhalten. Der Anwender selbst wünscht sich wohl ein Heimatverzeichnis mit entsprechenden Schreibrechten.

Nette Administratoren (und Distributionen) werfen ihre Nutzer auch bei den Programmeinstellungen nicht ins kalte Wasser, sondern konfigurieren vieles schon vor. Dabei lassen sich aber nicht alle Einstellungen zum Zeitpunkt der Einrichtung eines Accounts vornehmen, wenn etwa der erste tatsächliche Anmeldevorgang erst in weiter Zukunft erfolgt.

Benutzer anlegen

Der erste Schritt beim Anlegen eines Benutzers ist, Informationen über ihn in einer zentralen Datenbank zu speichern. Sofern dabei kein verteiltes System wie NIS , NIS+[1], Netinfo oder LDAP[2] Verwendung findet, sondern ein einzelner Computer all seine Nutzer lokal verwaltet, heißt die passende Datei dafür »/etc/passwd«. Diese einfach strukturierte Textdatei enthält für jeden Account den Login-Namen sowie User-ID, die Gruppen-ID der primären Benutzergruppe, das Homeverzeichnis und die bevorzugte Shell. Je nach Wunsch nimmt sie Zusatzinformationen wie Vor- und Nachnamen sowie Telefon- oder Raumnummer auf.

Früher haben Unix-Systeme in »/etc/passwd« auch ein verschlüsseltes Passwort gespeichert, das der Authentifizierung des Benutzers diente. Das Problem war, dass »/etc/passwd« von jedermann lesbar sein muss, also die Rechtemaske 0700 besitzt. Folglich war auch das verschlüsselte Passwort für jeden Benutzer lesbar. Mit heutigen Prozessoren dauert aber ein Brute-Force-Angriff (das massenhafte Durchprobieren von Passwörtern,[4]) vor allem auf schwache Passwörter nicht lange.

Ein Benutzer mit Zugriff auf das System hätte also die Möglichkeit, sich Zugang zu allen Accounts zu verschaffen. Um dieses Problem zu lösen, lagern die meisten Unixe alle Passwörter in die Datei »/etc/shadow« aus. Sie gehört »root« sowie der Gruppe »shadow« und ist meist nur für Root und manchmal zusätzlich von Angehörigen der Gruppe Shadow lesbar.

Alle anderen Benutzer haben keinen Zugriff mehr auf die Passwörter. Ein typischer »/etc/passwd«-Eintrag sieht folgendermaßen aus:

mas:x:1000:1000:Marc Andre Selig,,,:/home/mas:/bin/bash

Manche Unix-Systeme verwenden die Passwortdatei nicht direkt, sondern nutzen eine aus ihr generierte binäre Datenbank. Berüchtigt sind in dieser Hinsicht vor allem BSD-Abkömmlinge. Um jeden Konflikt auszuschließen und Race Conditions zu vermeiden, gibt es das Werkzeug »vipw«. Root sollte ausschließlich dieses Tool benutzen, um die Passwortdatei händisch zu bearbeiten. Es startet den Editor »vi« für »/etc/passwd«, lockt diese als Schutz vor zeitgleichen Zugriffen durch andere Admin-Nutzer und führt nach erfolgtem Editieren Aufräumarbeiten für eine binäre Nutzerdatenbank durch.

Neben den Benutzern selber sind Benutzergruppen ein zentraler Bestandteil der Rechtevergabe eines Unix-Systems. Admins legen sie ähnlich wie Benutzer an, und zwar mit den Kommandos »addgroup«, »groupadd« oder einem der Frontends. Jede Gruppe erhält einen Eintrag in der Datei »/etc/group«. Jede Datei erhält bei Erstellung einen User und eine Gruppe zugewiesen. Die Zugriffsrechte stellt der Besitzer oder der Admin dann getrennt ein, einmal für den Besitzer der Datei, einmal für die Gruppe.

Gruppen

So lassen sich mehrere Benutzer in einer Gruppe organisieren, die alle auf Dateien oder Verzeichnisse mit dieser Gruppenkennung Zugriff haben. Gängige Gruppen sind »modem« oder »dialout« für den Zugriff auf eine Modemschnittstelle, »audio« für die Soundkarte und »cdrom«, um die Rechte am CD-ROM-Laufwerk einzustellen. Gruppen regulieren oft auch den Zugriff auf freigegebene Verzeichnisse eines Fileservers.

Eine Reihe von administrativen Gruppen dient der Zugriffskontrolle auf Programme oder von Programmen auf bestimmte Dateien. So kennzeichnet »wheel« jene Benutzer, die das Programm »su« oder seine Äquivalente ausführen dürfen. Moderne Distributionen verzichten aus Gründen der Einfachheit meist auf sie und erlauben jedermann die Verwendung von »su«.

Abbildung 1: Benutzer unter Suse anlegen ist ein Kinderspiel. Die Feinarbeit erledigen Skripte im Hintergrund.

Für jeden etwas

Gruppen wie »tty«, »disk« und »lp« beziehen sich auf Systembestandteile (Zugang zu Terminals, Festplatten und Druckern), mit »bin« oder »sys« ist einstellbar, auf welche Dateien bestimmte Programme zugreifen dürfen. Menschliche Benutzer bekommen diese Gruppen niemals zugewiesen.

Die besondere Gruppe »nobody« (oder »nogroup«) soll die Rechtelosigkeit markieren, wird aber zur Gefahr, wenn mehrere Softwarepakete Dateien mit dieser Gruppenzugehörigkeit erstellen und die Gruppe daher zu Everybody mutiert. Besser ist es, jedem Paket eine eigene Nobody-Gruppe einzurichten.

Jeder Anwender darf Mitglied in vielen Gruppen sein, ist aber einer so genannten primären Gruppe zugeordnet. Sie legt vor allem fest, welcher der Gruppen die von ihm neu angelegten Dateien angehören. Um die primäre Gruppe temporär zu ändern, gibt es den Befehl »newgrp«, der als Parameter den Namen der neuen Gruppe erwartet. Die primäre Gruppe landet in »/etc/passwd«, alle anderen Zuordnungen stehen in »/etc/group«. Der Befehl »id« zeigt an, welchen Gruppen der gerade angemeldete Nutzer angehört:

mas@ishi:~$ id
uid=500(mas) gid=100(users) groups=100(users),14(uucp),16(dialout),17(audio),33(video)
mas@ishi:~$

Bei primären Gruppen verfolgen moderne Linux-Distributionen zwei unterschiedliche Praktiken: Manche legen eine gemeinsame Gruppe »users« für alle menschlichen Benutzer des Systems an. Die User kontrollieren dann mit »chmod«, ob ihre Dateien für Mitbenutzer lesbar sein sollen (Rechte 0640: Lese- und Schreibrecht für Eigentümer, Leserecht für Gruppe, keine Rechte für andere) oder nicht (0600: keine Rechte für Gruppe und andere).

Andere Distributionen geben jedem Benutzer eine eigene Gruppe. Das erleichtert den Datenschutz geringfügig und ermöglicht gezielte Teambildung, indem der Admin die Nutzer gegenseitig in die jeweiligen Gruppen aufnimmt.

Heimatverzeichnisse

Wenn der Admin die Benutzereinrichtung zu Fuß erledigen will, muss er dem Benutzer eine Heimat geben. Neben einem Eintrag von »/home/ Benutzer« in »/etc/passwd« sollte das Verzeichnis auch im Dateisystem vorhanden sein (Abbildung 2). Nach dem »mkdir« legt der Administrator auch die Benutzer- und Gruppenzugehörigkeit des Verzeichnisses mit »chown« fest.

Je nach Distribution und Präferenz der Admins erhalten Homeverzeichnisse die Rechte 0755, 0711 oder 0700. Die erste Variante gestattet jedermann den lesenden Zugriff auf das Verzeichnis. Die zweite erlaubt den Zugriff auf darin enthaltene Dateien und Verzeichnisse, sofern deren Rechte entsprechend gesetzt sind und der Name bekannt ist, verbietet aber das Anzeigen des Verzeichnislistings. Bei der dritten Einstellung ist das Verzeichnis für Fremde geschlossen. Da das Heimatverzeichnis dem neuen Nutzer gehört, darf er die Rechte nach Belieben abändern.

01 $ su
02 Password:
03 # vipw
04 ...
05 # passwd mas
06 # mkdir /home/mas
07 # cd /etc/skel && tar cf - . | (cd /home/mas && tar xpf -)
08 # chown -R mas:users /home/mas
09 # chmod -R u+rwX,go-rwx /home/mas
10 # exit
11 $

Abbildung 2: Viele Benutzer verwalten ist eine anspruchsvolle Aufgabe. Allein das Anlegen der Homeverzeichnisse erfordert detaillierte Kenntnisse.

Doch mit Anlegen von Home ist die Arbeit immer noch nicht erledigt. Jetzt gilt es, Voreinstellungen für gängige Programme sowie Umgebungsvariablen für den Benutzer einzustellen. Die Konfiguration der meisten Unix-Programme erfolgt über so genannte Dotfiles, also über versteckte Konfigurationsdateien (oder -verzeichnisse) im Heimatverzeichnis des aufrufenden Nutzers. Ihrem Namen ist stets ein Punkt vorangesetzt.

01 #!/bin/sh
02 # $Id: xinitrc,v 1.2 2003/02/27 19:03:30 jharper Exp $
03 
04 userresources=$HOME/.Xresources
05 usermodmap=$HOME/.Xmodmap
06 sysresources=/etc/X11/xinit/.Xresources
07 sysmodmap=/etc/X11/xinit/.Xmodmap
08 
09 # merge in defaults and keymaps
10 
11 if [ -f $sysresources ]; then
12     xrdb -merge $sysresources
13 fi
14 
15 if [ -f $sysmodmap ]; then
16     xmodmap $sysmodmap
17 fi
18 
19 if [ -f $userresources ]; then
20     xrdb -merge $userresources
21 fi
22 
23 if [ -f $usermodmap ]; then
24     xmodmap $usermodmap
25 fi
26 
27 # start some nice programs
28 
29 xterm &
30 
31 # start the window manager
32 
33 exec fvwm2

Ein Skelett

Ein Windowmanager sollte beispielsweise über installierte Software Bescheid wissen, um passende Menüs anbieten zu können. Textverarbeitungen und Bildbearbeitungssoftware sollen die lokal gängigen Maßeinheiten und Druckerparameter benutzen. Browser müssen über vorhandene Proxies informiert sein. Im Verzeichnis »/etc/skel/« (für Skelett) liegt das Grundgerüst jedes neuen Heimatverzeichnisses. Hier speichert der Admin Dotfiles, die jeder neue Nutzer erhalten soll. Beim Anlegen eines Heimatverzeichnisses kopiert er das Skelett in das neue Verzeichnis.

Abbildung 3: Beim Anlegen eines neuen Benutzers ist ein Geschwader von Aufgaben zu erfüllen. Werkzeuge wie »useradd« nehmen dem Admin diese Arbeit ab.

Damit ist der Benutzer inklusive seiner Umgebung endlich angelegt. Listing 1 zeigt, welche Befehle dafür notwendig sind. Weil diese Befehlsfolge beim häufigen Anlegen neuer Accounts doch etwas aufwändig ist, gibt es Werkzeuge wie zum Beispiel »adduser« und »useradd«, die alle diese Aufgaben übernehmen. Abbildung 3 illustriert übersichtlich die notwendigen Schritte.

Erweiterte Einstellungen

Ein besonderes Problem beim Vorkonfigurieren neuer Accounts besteht darin, dass viele Einstellungen nicht beliebig im Voraus festzulegen sind. Die Landessprache oder Zeitzone dürfte zwar in den meisten Fällen relativ unkritisch und stets gleich sein. Anders ist es aber mit programmspezifischen Feinheiten, die sich bei Updates ändern können. Es ist in einigen Umgebungen nämlich nicht sichergestellt, dass der neue Benutzer den Account sofort verwendet und die Konfigurationsoptionen ab dann selbstständig pflegt.

In vielen Fällen bietet es sich daher an, Konfigurationsdaten permanent an zentraler Stelle zu verwalten, sofern die jeweilige Applikation das unterstützt. Ein gutes Beispiel dafür sind die typischen X11-Windowmanager oder die Konfiguration von »xinit«. Hier sind lediglich die zentralen Konfigurationsbäume in »/etc/ X11/« zu pflegen. Bei Updates aktualisiert der Admin oder der Paketmanager diese Verzeichnisse und jeder Benutzer arbeitet automatisch mit den neuen Voreinstellungen. Sind fortgeschrittene Nutzer damit nicht zufrieden, nehmen sie eigene Einstellungen im Heimatverzeichnis vor.

Zentral ist einfacher

Listing 2 zeigt beispielhaft eine »/etc/ X11/xinit/xinitrc«, die Tastatur und Profil zunächst von zentraler Stelle initialisiert (Zeilen 11 bis 17). Hat ein Anwender eigene Einstellungen vorgenommen, lädt das Skript sie nach (Zeile 19 bis 25). In ähnlicher Weise setzen Admins Umgebungsvariablen in den zentralen Shellprofilen »/etc/profile« (für Sh und Bash) oder »/etc/csh.cshrc« und »/etc/csh.login« (für Csh und Tcsh).

Sofern der Nutzer eigene Versionen dieser Dateien im Heimatverzeichnis anlegt (als Dotfiles mit einem Punkt vor dem Dateinamen), führt die Shell sie beim Start aus, wodurch die darin enthaltenen Optionen zumindest bezüglich der Umgebungsvariablen Vorrang haben. Zentrale Einstellungen wie mit »ulimit« gesetzte Limits lassen sich so setzen, dass die erste, zentrale Einstellung Vorrang hat. Einzelne Variablen legen Admins in der Bash mit dem Befehl »readonly« als unveränderlich fest. So steuern sie sehr genau, welche Settings personalisierbar sind und welche nicht.

Sofern eine zentrale Verwaltung der Konfiguration nicht möglich ist, weil bestimmte Applikationen das gar nicht vorsehen und nicht ohne weiteres zu umgehen sind, gibt es noch einen einfachen Trick: Der Administrator ersetzt die Programmdatei durch ein Startskript. Dieses prüft, ob im Heimatverzeichnis bereits eine Version der Konfigurationsdaten existiert.

Falls nicht, kopiert es die Default-Einstellungen von zentraler Stelle und startet anschließend das eigentliche Programm. Je nachdem, wie viel Aufwand Admins betreiben möchten, könnten sie einem solchen Startup-Skript sogar beibringen, bei System-Updates die notwendigen Änderungen in der Konfiguration durchzuführen.

In großen Umgebungen ist es sinnvoll, Dienste wie LDAP und NIS für die Benutzerverwaltung einzusetzen. Der Schwerpunkt des vorigen Linux-Magazins behandelt die unter dem Namen Identity Management erfassten Technologien ausgiebig[4]. (mwe)