8.4 Als anderer Benutzer arbeiten 
Natürlich gibt es vor allem an Workstations, aber auch an tatsächlichen Mehrbenutzerrechnern teilweise die Notwendigkeit, als ein anderer Benutzer im System zu arbeiten. Im Folgenden wollen wir dafür einerseits Anwendungsbeispiele, andererseits aber natürlich auch Lösungsmöglichkeiten für dieses Problem angeben.
8.4.1 Der Systemadministrator als User 
Zu große Macht
Ein wichtiger Anwendungsfall für diese Problematik ist der Benutzer root. Dieser Benutzer ist aufgrund seiner Machtfülle nicht als Account eines Systemadministrators, sondern wirklich nur zum Erledigen wichtiger Aufgaben gedacht.
Stattdessen sollte ein Administrator für die tägliche Arbeit (wie zum Lesen von Mails lesen oder zum Websurfen) einen nichtprivilegierten Account nutzen und bei Bedarf eben schnell »root werden«.
Dies gilt natürlich im Besonderen, wenn ein Unix-Rechner »für zu Hause« genutzt und nur von einer einzigen Person verwendet wird. Auf Windows-Rechnern führt nämlich die Benutzung von privilegierten Accounts in der Regel dazu, dass diverse Viren, Würmer und Trojaner es relativ einfach haben, sich auf dem System häuslich einzurichten. Auch wenn Linux von diesen Gefahren noch nicht in einem solchen Ausmaß betroffen ist, so ist man als normaler Benutzer immer auf der sicheren Seite, da keine wichtigen Systemdateien oder -programme verändert werden können.
8.4.2 su
Möchte man nun als root oder ein anderer Benutzer arbeiten, so steht einem natürlich der Weg eines erneuten Logins offen. Da dies jedoch sehr umständlich ist, können Sie mit dem Programm su eine neue Shell als der gewünschte Benutzer starten. Alternativ kann man über den Parameter »-c« auch nur einen bestimmten Befehl zur Ausführung bringen.
Ohne Passwort
Auf jeden Fall muss – möchte man als normaler Benutzer unter fremden Rechten arbeiten – das Passwort des betreffenden Accounts angegeben werden. Einzig root kann ein normaler User werden, ohne ein Passwort angeben zu müssen.
Aber das hat auch einen Sinn: Schließlich gibt root Rechte ab, während normale Benutzer fremde Berechtigungen hinzugewinnen. Außerdem sollte ein Administrator die Passwörter seiner Benutzer nicht kennen, schließlich ist es das Wesen eines Passworts »geheim« zu sein.
Betrachten wir also ein Beispiel:
jploetner@host:/home/jploetner$ su Passwort: ******* root@host:/home/jploetner# su – swendzel swendzel@host:/home/swendzel$
Listing 8.25 su benutzen
In diesem Beispiel hat sich der Benutzer zuerst in root verwandelt: Gibt man nämlich bei su keinen Benutzernamen an, so wird das Passwort des Superusers abgefragt und bei Erfolg die entsprechende Shell gestartet.
Als root kann man schließlich ohne Passworteingabe jeder beliebige Benutzer werden.
Eine Besonderheit sei hier noch erwähnt: Ein Minus vor dem Benutzernamen <Natürlich kann man auch ein Minus als alleinigen Parameter an su übergeben, sodass man root werden kann.> macht die neue Shell zu einer Login-Shell. Daher wird in diesem Fall unter anderem das Arbeitsverzeichnis auf das Homeverzeichnis des neuen Benutzers gesetzt.
8.4.3 sudo
Ein einzelnes Programm ausführen
Das Programm sudo öffnet im Gegensatz zu su keine Shell mit der Identität des Benutzers, sondern wird genutzt, um ein Programm mit den entsprechenden Rechten zu starten. Wie auch bei su gilt: Ist kein Benutzer – hier über die Option -u – direkt angegeben, wird root als neue Identität genommen.
Die /etc/sudoers
Ein Aufruf von
$ sudo liloListing 8.26 sudo
führt das Programm lilo als root aus. Damit man nun als Benutzer die Vorzüge von sudo genießen kann, muss man mit einem entsprechenden Eintrag in der /etc/sudoers eingetragen sein:
… # Den Benutzern der Gruppe users ohne Passwort alles # erlauben %users ALL=(ALL) NOPASSWD: ALL # Dem Benutzer Test das Mounten/Unmounten von CD-ROMs # erlauben (hier wird der Befehl direkt angegeben) test ALL=/sbin/mount /cdrom,/sbin/umount /cdrom …
Listing 8.27 Die /etc/sudoers
Wie die Kommentare dieser Datei suggerieren, kann man für bestimmte Gruppen beziehungsweise Benutzer ziemlich genau einschränken, inwieweit sudo benutzt werden darf. Als Erstes wird dabei der Benutzer- beziehungsweise Gruppenname angegeben, worauf schließlich eine Liste der Form »Rechner=Befehle« die möglichen per sudo ausgeführten Befehle festlegt.
Netzwerk- transparenz
Würde die /etc/sudoers zum Beispiel über NIS oder NIS+ im Netzwerk verteilt werden, so könnte man anstatt »ALL=« sinnvolle Namen von Rechnern angeben, auf denen die nach dem »=« folgenden Befehle ausgeführt werden dürfen. Die Angabe von NOPASSWD: ALL in einer der Zeilen bewirkt zusätzlich, dass beim Aufruf von sudo für alle Befehle kein Passwort angegeben werden muss.
Anders als bei su muss bei sudo nicht das Passwort des zu benutzenden, sondern des eigenen Accounts angegeben werden.
Aus diesem Grund ist auch die besondere Konfiguration über die Datei /etc/sudoers notwendig. Schließlich ist sudo im engeren Sinn eine Verwässerung der Benutzerverwaltung und des Rechtesystems, die aber trotzdem ihre Daseinsberechtigung hat. Auf jeden Fall sollte man bei der Konfiguration von sudo Vorsicht walten lassen.
Für die normalen Anwendungsfälle sollten diese Beispiele eigentlich ausreichen. Für wirklich exotische Setups helfen dann die Manpages zu sudo und zur sudoers-Datei weiter.
8.4.4 SetUID/SetGID
Eine weitere Möglichkeit, die Berechtigungen eines anderen Users zu nutzen, sind die SetUID/SetGID-Bits. Diese Rechte werden auf Dateien gesetzt, die nicht mit den Rechten des ausführenden Users, sondern mit denen des Eigentümers beziehungsweise der Gruppe der Datei ausgeführt werden sollen. Diese Zusammenhänge werden von uns bei der Behandlung des Rechtesystems näher besprochen.
