13.4 Als ein anderer Benutzer arbeiten

Natürlich gibt es vor allem an Arbeitsplatzrechnern, aber auch an tatsächlichen Mehrbenutzerrechnern, manchmal die Notwendigkeit, als ein anderer Benutzer im System zu arbeiten. Im Folgenden wollen wir dafür einerseits Fallbeispiele, andererseits aber natürlich auch Lösungsmöglichkeiten für damit einhergehende Probleme angeben.

13.4.1 Der Systemadministrator als User

Zu große Macht

Ein wichtiger Problemfall ist der Benutzer root. Dieser Account ist aufgrund seiner Machtfülle nicht als persönliches Konto 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 dauernde 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, ist man als nichtprivilegierter 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. Zudem 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:

Listing 13.26 su benutzen

jploetner@host:/home/jploetner$ su
Passwort: ********
root@host:/home/jploetner# su – swendzel
swendzel@host:/home/swendzel$

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 [Fn. 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 ausgewählt.

Die Datei /etc/sudoers

Der folgende Aufruf führt das Programm lilo als root aus:

Listing 13.27 sudo

$ sudo lilo

Damit man als Benutzer die Vorzüge von sudo genießen kann, muss man mit einer entsprechenden Zeile in der Datei /etc/sudoers eingetragen sein:

Listing 13.28 Die Datei /etc/sudoers

...
# 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
...

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.

Netzwerktransparenz

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. In jedem 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 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 bei Dateien gesetzt, die nicht mit den Rechten des ausführenden Users, sondern mit denen des zugeordneten Eigentümers beziehungsweise der zugeordneten Gruppe der Datei ausgeführt werden sollen. Diese Zusammenhänge werden von uns im Zusammenhang mit dem Rechtesystem näher besprochen.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.