13.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.
13.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. Ein Administrator sollte für die tägliche Arbeit (wie zum Lesen von Mails oder zum Websurfen) einen nichtprivilegierten Account nutzen und bei Bedarf schnell root werden können.
Dies gilt vor allem dann, wenn ein Unix-Rechner 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 gleichem Maße betroffen ist, so ist man als normaler Benutzer immer auf der sicheren Seite, da keine wichtigen Systemdateien oder -programme verändert werden können.
13.4.2 su 

Möchte man nun als root oder als ein anderer Benutzer arbeiten, so steht einem zunächst 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 müssen Sie, um als normaler Benutzer unter fremden Rechten zu arbeiten, das Passwort des betreffenden Accounts angeben. Einzig root kann ein normaler User werden, ohne ein Passwort angeben zu müssen. Aber dies ist auch sinnvoll: 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 13.26 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 können Sie sich schließlich ohne Passworteingabe in jeden beliebigen Benutzer verwandeln.
Eine Besonderheit sei hier noch erwähnt: Ein Minuszeichen vor dem Benutzernamen [Natürlich kann man auch ein Minus als alleinigen Parameter an su übergeben, um root zu werden.] macht die neue Shell zu einer Login-Shell. Daher wird in diesem Fall unter anderem das Arbeitsverzeichnis auf das Home-Verzeichnis des neuen Benutzers gesetzt.
13.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 Datei /etc/sudoers
Ein Aufruf von
$ sudo lilo
Listing 13.27 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 Datei /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 13.28 Die Datei /etc/sudoers
Wie die Kommentare dieser Datei suggerieren, kann man für bestimmte Gruppen und Benutzer ziemlich genau einschränken, inwieweit sudo benutzt werden darf. Als Erstes wird dabei der Benutzer- beziehungsweise der Gruppenname angegeben, woraufhin 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. Bei wirklich exotischen Setups helfen Ihnen dann die Manpages zu sudo und zur sudoers-Datei weiter.
13.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.