13.2 Benutzer anlegen, ändern und löschen
Kommen wir nun zur praktischen Benutzerverwaltung und somit zu den Programmen, mit denen man bspw. neue Nutzer anlegen kann. Solche Programme kümmern sich im Normalfall um Feinheiten wie um die Wahl einer noch freien UID.
13.2.1 Benutzer anlegen
Zum Anlegen neuer Benutzer gibt es im Wesentlichen zwei distributionsunabhängige Hilfsprogramme: useradd und adduser. Natürlich hat auch jede Distribution noch ihr eigenes Administrationstool, mit dem sich weitere Benutzer anlegen lassen. Schließlich wird während der Installation auf jeden Fall das Administratorkonto root sowie im Regelfall noch mindestens ein Benutzerkonto konfiguriert.
Beide Programme funktionieren nun so, wie man es erwarten würde: useradd verhält sich ganz konform zur Unix-Philosophie. Alle Informationen müssen vom Bediener – im Regelfall kann nur der Administrator root neue Benutzer anlegen – per Parameter an das Programm übergeben werden.
Viele Möglichkeiten
Ruft man useradd ohne Option auf, werden die verfügbaren Parameter angezeigt:
Listing 13.4 useradd ohne Argument
# useradd
usage:
useradd name [-u uid [-o]] [-g group,..] [-G group]
[-d home] [-s shell] [-c comment]
[-m [-k template]] [-f inactive]
[-e expire ] [-p passwd]
useradd -D [-g group] [-b base] [-s shell]
[-f inactive] [-e expire ]
Man kann über die Kommandozeile also entweder einen neuen Benutzer anhand seines Benutzernamens anlegen oder auch die Voreinstellungen (Default, -D) entsprechend ändern. Gibt man nur den Benutzernamen an, wird ein wie folgt aussehender Eintrag in der Datei /etc/passwd angelegt:
Listing 13.5 Anlegen eines Benutzers mit useradd
# useradd johannes
# grep johannes /etc/passwd
johannes:x:1002:100::/home/elena:
# grep johannes /etc/shadow
johannes:!:12895:0:99999:7:::
# ls /home/johannes
ls: /home/johannes: No such file or directory
Konservative Voreinstellungen
Wie man sieht, verhält sich useradd wirklich streng konservativ gemäß der Unix-Philosophie: Der Benutzer wird ohne gültiges Passwort und ohne eigens angegebene Login-Shell [Fn. Ist das Feld in der /etc/passwd leer, wird der Standardwert /bin/sh benutzt.] mit der nächsten freien UID angelegt; ein Home-Verzeichnis wird nicht erstellt. [Fn. Natürlich kann man über verschiedene Kommandozeilenoptionen, wie im Listing zu sehen, auch einen funktionierenden Account erstellen.] Auch bleibt der Befehl im Erfolgsfall stumm – typisch Unix.
Möchte man das Standardverhalten nun ändern und einen Benutzer nicht zur Gruppe users – die eigentlich auf allen Systemen die GroupID 100 hat --, sondern zu einer anderen Gruppe hinzufügen, so kann man den Switch -D nutzen. Die Konfiguration wird schließlich in der Datei /etc/default/useradd gespeichert, einem typischen Verzeichnis für solche Konfigurationen.
Im Verzeichnis /etc/default sind sinnvolle Vorbelegungen für sehr viele einzelne Programme oder Systemteile gespeichert. Die Konfigurationsdateien heißen dabei in der Regel wie das Programm selbst.
Freundlicheres Frontend
Im Regelfall möchte man jedoch eine intuitivere Möglichkeit zum Anlegen von Benutzern haben. Her kommt das Programm adduser ins Spiel, ein Frontend für useradd. Bei adduser wird ein neuer Benutzer auch ohne weitere Kommandozeilenoptionen fertig angelegt. Dazu wird der Administrator jedoch während der Erstellung des Benutzers nach wichtigen Daten gefragt: [Fn. Das widerspricht auf den ersten Blick natürlich der Unix-Philosophie. Wenn man aber sieht, dass dieses Tool nur ein vereinfachendes Frontend und damit eine Alternative für den klassischen Weg ist, wird alles wieder konsistent. Schließlich hat man die Wahl.]
Listing 13.6 Den Benutzer »jploetner« anlegen
# adduser jploetner
Adding user `jploetner'...
Adding new group `jploetner' (1001).
Adding new user `jploetner' (1001) with group `jploetner'.
Creating home directory `/home/jploetner'.
Copying files from `/etc/skel'
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for jploetner
Enter the new value, or press ENTER for the default
Full Name []: Johannes Plötner
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [y/N] y
Der auffälligste Unterschied bei der Nutzung beider Programme besteht nun darin, dass man bei adduser im Gegensatz zu useradd auch ohne eine lange Liste von Kommandozeilenoptionen einen funktionierenden Account bekommt. Die wichtigsten Unterschiede wollen wir im Folgenden betrachten:
- Eigene Gruppe
Der neu erstellte Benutzer bekommt eine eigene Gruppe mit seinem eigenen Namen. Zwar kann man auch bei useradd mit dem -g-Parameter eine beliebige Gruppe angeben, welcher der Benutzer dann hinzugefügt wird, jedoch muss diese Gruppe bereits existieren. Da man Benutzer natürlich auch mehreren Gruppen hinzufügen kann, ist eine exklusive Gruppe für jeden neuen Benutzer zunächst einmal ein sicherer Ansatz. - Ein eigenes Home-Verzeichnis
Bei useradd wurde zumindest ohne Angabe des Parameters -d zwar ein Home-Verzeichnis in die Datei /etc/passwd eingetragen, es wurde aber nicht angelegt.
Vorlage für das Home-Verzeichnis
- Ein fertiges Passwort
Während der Erstellung des Benutzerkontos wird man aufgefordert, das Passwort für das neue Konto einzugeben. Da Passwörter unter Unix/Linux üblicherweise nicht angezeigt werden, [Fn. Schließlich lässt zum Beispiel die Anzahl der »Sternchen« einen Rückschluss auf die Länge des Passworts zu.] wird man aufgefordert, die Eingabe zu wiederholen. Bei useradd dagegen kann man das Passwort über den -p-Parameter setzen, wobei hier aber schon das verschlüsselte Passwort als Eingabe erwartet wird. [Fn. Das Passwort muss mit der Bibliotheksfunktion crypt() verschlüsselt sein.] - Benutzerinformationen
Wie unschwer zu sehen ist, wird man bei adduser aufgefordert, diverse Daten über den Benutzer einzugeben. Diese werden dann, durch Kommata getrennt, im frei verwendbaren Feld der Datei /etc/passwd gespeichert. Bei useradd muss man dazu den Parameter -c, gefolgt vom gewünschten Kommentar, angeben. - Shell
Zu guter Letzt einer der wichtigsten Punkte: die Shell. Bei useradd wurde ohne den -s-Parameter keine Shell eingetragen und somit die Default-Shell /bin/sh genutzt. Bei adduser jedoch wird eine – für gewöhnlich »bessere« – Shell in die /etc/passwd eingetragen.
Bei adduser jedoch wird auch standardmäßig die Vorlage für neue Home-Verzeichnisse – das Verzeichnis /etc/skel – an die entsprechende Stelle kopiert und mit den Benutzer- und Gruppenrechten des neuen Users versehen. Wenn Sie als Administrator den Inhalt eines neuen Home-Verzeichnisses verändern möchten, vielleicht um angepasste Konfigurationen oder kleine Hilfedateien unterzubringen, müssen Sie also das Verzeichnis /etc/skel anpassen.
Sehen wir uns also abschließend noch den von adduser in der Datei /etc/passwd angelegten Eintrag an:
Listing 13.7 Der neue Eintrag in der /etc/passwd
# grep jploetner /etc/passwd
jploetner:x:1001:1001:Johannes Ploetner,,,:/home/jploetner:\
/bin/bash
Standardeinstellung ändern
Die Einstellungen für sinnvolle Defaultwerte (beispielsweise für die Standardshell) kann man wie bei useradd auch in einer Konfigurationsdatei – der /etc/adduser.conf – vornehmen. Diese ist sehr gut dokumentiert, und außerdem gibt es noch eine Manpage zur Syntax. Daher wollen wir uns auch nur einen Ausschnitt dieser Datei ansehen, um einen Eindruck von den vorhandenen Optionen und Konfigurationsmöglichkeiten zu bekommen:
Listing 13.8 Ein Auszug aus der /etc/adduser.conf
...
# The USERGROUPS variable can be either "yes" or "no".
# If "yes" each created user will be given their own
# group to use as a default, and their home directories
# will be g+s. If "no", each created user will be
# placed in the group whose gid is USERS_GID.
USERGROUPS=yes
# If USERGROUPS is "no", then USERS_GID should be the
# GID of the group 'users' (or the equivalent group) on
# your system.
USERS_GID=100
...
In diesem Abschnitt der Datei wird das Verhalten hinsichtlich der Benutzergruppen geregelt: Ist die Variable USERGROUPS auf yes gesetzt, so bekommt jeder neue Benutzer eine eigene Gruppe – es passiert also genau das, was wir in unserem adduser-Beispiel gesehen haben. Setzt man sie auf no, erreicht man ein ähnliches Verhalten wie bei useradd, da der neue Benutzer dann der Gruppe zugewiesen wird, die in USERS_GID festgelegt ist.
Abbildung 13.1 Neuen Benutzer unter SUSEs YaST2 anlegen
Unterschiede der Distributionen
Nachdem wir also die Repräsentation der Benutzer im System über die IDs im Prozesskontrollblock und die Informationen in der /etc/passwd besprochen sowie die distributionsunabhängigen Programme useradd und adduser zum Anlegen neuer Benutzer erklärt haben, wollen wir noch kurz ein Wort über distributionsabhängige Möglichkeiten, neue Benutzer anzulegen, verlieren.
Prinzipiell werden Sie bei grafischen Administrations-Frontends wie YaST2 von (open-)SUSE mit denselben Fragen nach Benutzernamen, bürgerlichem Namen und Passwort wie bei adduser behelligt. Oft sehen auch die Home-Verzeichnisse »besonders« aus, zum Beispiel wenn es ein ~/Documents- oder ein ~/public_html-Verzeichnis gibt. Wenn Sie also diese Voreinstellung ändern wollen, wissen Sie nun, dass Sie im /etc/skel-Verzeichnis nachsehen müssen.
13.2.2 Benutzer ändern
Der nächste interessante Punkt ist das Ändern von Benutzerdaten. Auch wenn es vielleicht nicht offensichtlich ist – das Ändern dieser Daten ist oft wichtig. Vor allem in Mehrbenutzersystemen müssen manchmal Accounts deaktiviert oder Benutzer zum regelmäßigen Ändern des Passworts angehalten werden.
Das Passwort ändern
Diese vielleicht häufigste Änderung an den Benutzerdaten führt man als einfacher Benutzer in der Regel selbst mit dem passwd-Programm durch:
Listing 13.9 Ein neues Passwort mit passwd setzen
jploetner@workstation:~$ passwd
Changing password for jploetner
(current) UNIX password:
Enter new UNIX password:
passwd: password updated successfully
jploetner@workstation:~$
Dieses fragt einmal nach dem alten Passwort und zweimal nach dem neuen, da das Passwort wie üblich während der Eingabe nicht angezeigt wird. Nun gibt es aber auch die Situation, in der der Administrator das Passwort für einen Benutzer neu setzen muss – etwa weil dieser es vergessen hat. Dazu ruft der Administrator das Programm passwd mit dem Benutzernamen als Argument auf:
Listing 13.10 Der Admin ändert das Passwort für einen Benutzeraccount.
# passwd jploetner
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Dabei wird root natürlich nicht nach dem Passwort gefragt: Erstens muss er es nicht wissen, [Fn. Schließlich kann root auf die /etc/shadow auch schreibend zugreifen und so das Passwort, wenn auch in verschlüsselter Form, leicht selbst neu setzen.] und zweitens geht das alte Passwort den Admin nichts an.
Die naheliegendste Möglichkeit für weitergehende Änderungen an den Benutzerkonten ist nun das direkte Editieren der Datei /etc/passwd beziehungsweise der Datei /etc/shadow. Soll zum Beispiel ein Account auf diese Art deaktiviert werden, so besteht eine Möglichkeit darin, einfach ein Ausrufezeichen vor das verschlüsselte Passwort in der /etc/shadow zu setzen. Dieses ist nämlich ein Zeichen, das bei der Verschlüsselung eines Passworts nicht entstehen kann. Daher wird nun also das richtige wie auch jedes andere denkbare Passwort in seiner verschlüsselten Form nicht mit dem verschlüsselten Passwort in der /etc/shadow übereinstimmen und das Login somit fehlschlagen.
usermod
Ein anderer, weniger umständlicher Weg ist es, das Programms usermod zu nutzen. Mit ihm kann man alle nötigen Felder der Dateien setzen und verändern. Alle möglichen Optionen erhält man wie bei useradd durch Eingabe des Befehls ohne Argumente oder eben in der Manpage:
Listing 13.11 Die Optionen von usermod
# usermod
usage:
usermod [-u uid [-o]] [-g group] [-G group,...]
[-d home [-m]] [-s shell] [-c comment]
[-l new_name] [-f inactive] [-e expire ]
[-p passwd] [-L|-U] name
Um den Benutzer zu identifizieren, den man ändern will, muss man also den Login- bzw. Benutzernamen angeben. Darauf lassen sich UID, GID, weitere Gruppenzugehörigkeiten, das Home-Verzeichnis, die Shell, der Kommentar, der Benutzername selbst sowie natürlich das Passwort – das hier wieder nicht im Klartext, sondern bereits verschlüsselt angegeben werden muss --, ändern.
Aber auch die Inaktivitätseinstellungen für Accounts können mit diesem Programm verändert werden. Da diese bei Mehrbenutzersystemen recht oft Verwendung finden, wollen wir sie uns im Folgenden daher gezielt ansehen:
- -L
Hiermit wird ein Account mit sofortiger Wirkung auf »inaktiv« gesetzt. Der entsprechende Benutzer kann sich mit seinem Passwort in Zukunft nicht mehr einloggen, da – wie bereits erläutert – diese Option dazu führt, dass ein Ausrufezeichen vor das verschlüsselte Passwort in der /etc/shadow gesetzt wird. - -U
Diese Option reaktiviert einen vorher mittels usermod -L username ausgeschalteten Account.
Nur die shadow
- -e Ablaufdatum
Hiermit können Sie ein Datum festlegen, ab dem der Account deaktiviert ist. Es muss in der Form »JJJJ-MM-TT« angegeben werden. Intern wird natürlich das entsprechende Feld in der /etc/shadow gesetzt:
Listing 13.12 Das Ablaufdatum für einen Account setzen
# grep jploetner /etc/shadow
jploetner:$1$fy...dssKXM.9aLU.1:12897:0:99999:7:::
# usermod -e 2005-04-28 jploetner
# grep jploetner /etc/shadow
jploetner:$1$fy..dsKXM.9aLU.1:12897:0:99999:7::12901:
- -f Inaktivität
Hiermit können Sie nun die Anzahl der Tage nach Ablauf des Passworts angeben, nach denen der Account schließlich deaktiviert wird. Geben Sie hier 0 an, erfolgt die Deaktivierung sofort nach Ablauf des Passworts; eine –1 schaltet das Feature hingegen ab.
Das Datum wird dabei also offensichtlich durch usermod aus der für einen Benutzer leicht lesbaren Form in die etwas umständliche Notation »Tage ab dem 1. Januar 1970« [Fn. Also ab dem Beginn der »Unix-Zeit«.] konvertiert.
Wie Sie sehen, kann mit usermod die Handhabung der Konfigurationsdateien zur Benutzerverwaltung mitunter deutlich vereinfacht werden. Außerdem ist dieses Tool auch bei anderen Unix-Varianten vorhanden und erleichtert so den Umstieg, da /etc/passwd und /etc/shadow unter Umständen etwas anders aufgebaut oder auch benannt sein können.
13.2.3 Benutzer löschen
Dateien nicht vergessen
Natürlich gibt es auch Programme, die einem beim Löschen eines nicht mehr benötigten Benutzers helfen. Besonders interessant ist in diesem Fall das Löschen der Dateien des Benutzers: Schließlich hat ein User vielleicht nicht nur sein Home-Verzeichnis, sondern auch noch ein E-Mail-Verzeichnis unterhalb von /var/mail sowie andere Dateien oder Verzeichnisse, auf die er noch Rechte besitzt.
[zB]Betrachten wir dazu folgendes Beispiel: Eine Datei test.txt gehöre einem Benutzer andreas mit UID 1003, der aber ohne Rücksicht auf seine Dateien gelöscht wurde. Das folgende Beispiel zeigt den Effekt der Löschung auf die Datei:
Listing 13.13 Listing der Datei test.txt
# ls -l test.txt
-rw-rw---- 1 1003 1003 0 2005-04-17 21:25 test.txt
Unbekannte Benutzer
Man kann unschwer erkennen, dass anstelle des Benutzer- und Gruppennamens im langen Dateilisting von ls nur noch die UID und die – in diesem Fall identische – GID angezeigt werden. Schließlich wird im System intern nur die UID beziehungsweise die GID zur Identifikation eines Benutzers herangezogen. So konnte die im Dateikopf – der Inode – gespeicherte UID/GID nicht mehr in einen Benutzernamen übersetzt werden und musste daher »pur« angezeigt werden.
Damit es in solchen Fällen nicht zu Verwechslungen mit eventuell existierenden Benutzernamen kommt, müssen Benutzernamen immer mit einem Buchstaben beginnen.
Sehen wir uns jetzt an, welche Programme uns zum Löschen eines Benutzers zur Verfügung stehen. Der viel gepriesenen Logik und Konsistenz von Unix und damit auch von Linux folgend müssten wir die zwei Programme userdel und deluser zur Verfügung haben – und so ist es auch. [Fn. Wie Sie sicherlich schon bemerkt haben, ist einzig bei usermod kein moduser-Äquivalent geläufig.]
Die Basis bildet wieder einmal userdel: Gibt man außer dem Benutzernamen keine weiteren Parameter an, so wird der Benutzer einfach aus der /etc/passwd und der /etc/shadow gelöscht. Seine Dateien im Home- und Mail-Verzeichnis werden jedoch nur gelöscht, wenn man zusätzlich die -r-Option auf der Kommandozeile angibt.
deluser
Dagegen bietet wie gewohnt das deluser-Frontend einige weitere Optionen. Ohne weitere Parameter wird natürlich wieder nur der User selbst, aber nicht dessen Dateien gelöscht. Die Parameter jedoch sind etwas anders und erlauben ein differenzierteres Vorgehen als bei userdel:
- --remove-home
Mit dieser Option wird das Home-Verzeichnis des zu löschenden Benutzers entfernt. - --remove-all-files
Diese Option löscht dagegen wirklich alle Dateien des Benutzers – also nicht nur das Home-Verzeichnis und die Mail-Dateien. Mit dieser Option ist der Parameter --remove-home unnötig. - --backup
Interessanterweise kann man die zu löschenden Dateien auch sichern lassen. Das Backup wird schließlich in Form einer komprimierten Datei ins aktuelle Verzeichnis abgelegt.
[zB]Natürlich werden wir diese Vorgehensweise an einem Beispiel veranschaulichen:
Listing 13.14 Einen Benutzer und alle seine Dateien löschen
# deluser --remove-all-files --backup jploetner
Looking for files to backup/remove...
Backing up files to be removed to . ...
/bin/tar: Removing leading `/' from member names
Removing files...
Removing user `jploetner'...
done.
# ls
jploetner.tar.bz2
Hiermit wollen wir uns von der puren Benutzerverwaltung verabschieden und uns den Gruppen zuwenden.
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.