Wer unter Linux häufig Befehle als Root absetzt, entdeckt schnell das Kommando Sudo, das viele Administrationsaufgaben erleichtert. Noch komfortabler ist das Tool Op.

Linux ist ein Mehrbenutzersystem – der Zugang zum privilegierten Root-Account ist darum auf vielen Rechnern gut geschützt. Oft reichen jedoch die Rechte normaler Anwender nicht aus, um beispielsweise eine CD oder einen Memory Stick einzubinden. Ohne Auto-Mounter ist guter Rat teuer. Auch die Einwahl ins Internet konfigurieren manche Distributionen so, dass sie Root-Rechte erfordern.

Ist der Benutzer gleichzeitig auch der Administrator (wie bei den meisten privat genutzten PCs), reicht es in der Regel aus, mit dem Befehl su und Eingabe des Administratorpassworts Root-Rechte zu erlangen – für die Befehle, die Sie nach Wechsel eingeben, gilt aber das Gleiche wie für die (nicht empfohlene) permanente Arbeit als Root: Kleine Tippfehler haben oft verhehrende Folgen.

Abhilfe schafft ein Szenario, in dem Benutzer nur eine vom Administrator festgelegte Auswahl von Befehlen mit Root-Rechten ausführen dürfen: Um dem Anwender beispielsweise das Mounten des USB-Sticks zu erlauben, braucht es ansonsten keine weiteren Privilegien. Das Root-Passwort darf geheim bleiben.

Klassiker Sudo

Eine bewährte Lösung des Problems liefert das Kommando sudo[2], mit dem auch Normalbenutzer einige Befehle mit Root-Privilegien ausführen dürfen, wenn der Administrator diese freigegeben hat.

Manche Linux-Distributionen (zum Beispiel Ubuntu und Knoppix) verwenden Sudo heute, um den Standardbenutzer praktisch zum Administrator zu machen, indem sie in der Konfigurationsdatei /etc/sudoers einen Eintrag der Form <§§I>Benutzername<§§I> ALL = (root) ALL anlegen.

In diesem Fall darf jeder Benutzer beliebige Befehle als Root absetzen, indem er dem gewünschten Befehl das Wort sudo voranstellt, also beispielsweise sudo killall -9 <§§I>Befehl<§§I>, um alle Prozesse namens <§§I>Befehl<§§I> abzuschießen. Nach diesem Aufruf fordert Sudo zur Sicherheit nur das eigene Passwort des Benutzers an; danach startet es den Befehl mit Root-Rechten.

Abbildung 1: Die Web-Seite zu Sudo bietet auch ausführliche Informationen zur Konfiguration.

Wollen Sie etwas genauer festlegen, wer welche Befehle ausführen darf, macht Sudo auch dies möglich – soll etwa der Benutzer abc den Befehl tail -f /var/log/messages ausführen dürfen, ergänzen Sie die Datei /etc/sudoers um die Zeile

abc ALL = (root) tail -f /var/log/messages

Der Benutzer muss den Befehl dann allerdings exakt in dieser Form eingeben, lediglich zusätzliche Leerzeichen akzeptiert Sudo ohne Kritik. Schon ein Weglassen des Parameters -f oder ein Ändern der Reihenfolge führen allerdings zu einer Fehlermeldung:

[abc@kira ~]$ sudo tail /var/log/messages -f
Sorry, user abc is not allowed to execute '/usr/bin/tail /var/log/messages -f' as root on kira.
[abc@kira ~]$ sudo tail -f /var/log/messages
Mar 31 14:13:39 kira – MARK –
Mar 31 14:33:39 kira – MARK –
[…]

Derart privilegierte Anwender müssen sich also die erlaubten Befehle präzise merken – oder vor jedem Aufruf mit sudo -l prüfen, welche Möglichkeiten das Programm ihnen eröffnet:

[abc@kira ~]$ sudo -l
User abc may run the following commands on this host:
    (root) /usr/bin/tail -f /var/log/messages

Jeder fehlerhafte Sudo-Aufruf führt zu einem Eintrag im Log, und auf manchen Rechnern schickt Sudo sogar eine Warn-Mail an den Systemadministrator.

Alternative Op

Kaum bekannt ist das Tool Op, das sich als Sudo-Ersatz anbietet und unter anderem durch eine einfachere Syntax der Konfigurationsdatei sowie komfortablere Aufrufmöglichkeiten für die Anwender auffällt. Für einfache Befehle reicht ein einzeiliger Eintrag aus, der stets dem Aufbau

Kurzbefehl Befehl; Optionen

folgt. Wollen Sie beispielsweise dem Benutzer abc erlauben, den Rechner mit halt herunter zu fahren, eignet sich dafür die Zeile

halt /sbin/halt; users=abc

Möchten Sie, dass er dazu (wie bei Sudo üblich) sein Passwort angibt, ergänzen Sie die Option password:

halt /sbin/halt; users=abc p?
assword

Auf diese Weise konfigurieren Sie Op in wenigen Minuten für die wichtigsten Aufgaben. Zu beachten ist nur, dass Sie bei Programmen den vollen Pfad (im Beispiel /sbin/halt statt halt) angeben müssen. Der Anwender abc gibt dann in der Shell den Befehl op halt ein, um den PC herunter zu fahren.

Software übersetzen

Wie die meisten Programme, übersetzen Sie auch Op mit dem klassischen Dreischritt, wobei Sie configure zwei Optionen übergeben:

./configure --prefix=/usr --sysc?
onfdir=/etc
make
make install

Ohne die Prefix-Option installiert sich das Programm unterhalb von /usr/local/, und ohne die Option --sysconfdir würde es die Konfigurationsdateien in $PREFIX/etc/ suchen.

Im Test ließ sich die aktuelle Version 1.32 von Op unter Suse Linux 9.3 problemlos installieren; unter Debian Sarge lief make erst nach einem apt-get install flex durch.

Beispiele

Legen Sie mit mkdir -p /etc/op.d ein Konfigurationsverzeichnis für Op an, erzeugen Sie als erstes Beispiel eine Datei /etc/op.d/log.conf wie in Listing 1 gezeigt und setzen Sie mit chmod 600 /etc/op.d/log.conf passende Rechte: Nur Root darf diese Datei lesen oder schreiben. Vergessen Sie den Chmod-Aufruf, funktioniert das Programm nicht (und präsentiert eine in die Irre führende Fehlermeldung, dass es keine Konfigurationsdatei findet).

messages  /bin/cat /var/log/messages; users=abc
syslog    /bin/cat /var/log/syslog; users=abc

Die beiden Zeilen aus Listing 1 erzeugen zwei neue Kurzbefehle messages und syslog, so dass der Anwender abc die beiden Log-Dateien mit den Kommandos op messages und op syslog öffnen darf. Das Listing führt für Cat den vollen Pfad /bin/cat auf, da Op das Dienstprogramm sonst nicht findet.

Op-Skripte

Ein nützliches Feature von Op ist die Möglichkeit, kleine Shell-Skripte direkt in der Konfigurationsdatei abzulegen. Listing 2 zeigt ein Beispiel, das den Op-Kurzbefehl log definiert, über den zugelassene Anwender die Dateien /var/log/messages und /var/log/syslog lesen dürfen: Skripte können weitere Argumente auslesen und verwerten, genau wie bei normalen Skripten geschieht das über die Umgebungsvariablen $1, $2 etc. Der zweite Kurzbefehl in Listing 2, apache, ermöglicht das Starten und Beenden des Apache-Dienstes. Das Skript für den Kurzbefehl log definiert die Variable $TERM, damit der Less-Befehl funktioniert.

Die neuen Befehlsdefinitionen speichern Sie in weiteren Dateien im Verzeichnis /etc/op.d/ (die wieder nur für Root lesbar sein dürfen); alternativ können Sie auch alle Definitionen in eine einzige Datei schreiben.

log     /bin/sh -c '
        export TERM=xterm
        case $1 in
          messages) less /var/log/messages ;;
          syslog)   less /var/log/syslog ;;
          *) echo "op: Sie dürfen die Log-Datei \'$1\' nicht lesen" ;;
        esac
        ';
        users=abc
        help="Log-Dateien ansehen (nur: messages und syslog)"
apache  /bin/sh -c '
        case $1 in
          start|stop) /etc/init.d/apache $1 ;;
          *) echo "op: apache akzeptiert nur start und stop" ;;
        esac
        ';
        users=abc
        help="Apache-Server starten und stoppen"

Welche Kurzbefehle ein Benutzer aufrufen darf, zeigt Op an, wenn Sie es mit der Option -l aufrufen – Kurzbefehle, die nur für andere Benutzer gelten, blendet das Programm also aus. Fehleingaben fängt das kleine Skript ab und teilt dem Anwender mit, dass er nur die Dateien messages und syslog lesen darf:

abc@amd64:~> op -l
apache  Apache-Server starten un?
d stoppen
log     Log-Dateien ansehen (nur?
: messages und syslog)
abc@amd64:~> op log security
op: Sie dürfen die Log-Datei 'se?
curity' nicht lesen

Die Op-Skripte sind einer der Vorteile von Op gegenüber Sudo: Um mit dem Klassiker das gleiche Resultat zu erreichen, müssten Sie ein Skript schreiben, im Dateisystem (zum Beispiel in /usr/local/bin) ablegen und dann in /etc/sudoers Anwendern erlauben, dieses Skript aufzurufen. Bei Änderungen wäre dann stets ein Blick in das Skript und zusätzlich in die Sudo-Konfigurationsdatei nötig – Op fasst beides in einer einzigen Datei zusammen.

Fremde Nutzer

Dass Op wirklich nur die unter users= angegebenen Benutzer einen privilegierten Befehl ausführen lässt, überprüfen Sie leicht, indem Sie das Kommando unter der Kennung nobody aufrufen:

amd64:# su - nobody
nobody@amd64:~> op -l
nobody@amd64:~> op log messages
log: permission denied by op

Die Liste der zulässigen Op-Befehle für nobody ist leer, und den Versuch, die Log-Datei anzusehen, bestraft die Software mit einer Fehlermeldung (und darüber hinaus mit einem Eintrag in der Protokolldatei /var/log/auth.log beziehungsweise /var/log/messages):

Feb  8 14:56:52 amd64 op[471?
6]: nobody log messages: Both us?
er, group and netgroup authentic?
ation failed

Abbildung 2: Op ist schnell eingerichtet – die Abbildung zeigt Teile einer komplexeren Konfiguration.

Benutzergruppen

Genau wie Sudo kann auch Op mehrere Benutzer zu Gruppen zusammenfassen und diesen dann auf einen Schlag neue Rechte geben oder welche nehmen. Gibt es etwa drei Benutzer abc, def und ghi, die verschiedene Systemverwaltungsaufgaben übernehmen sollen, fassen Sie diese zu einer Gruppe ADMINS zusammen. Das erledigt ein Eintrag

ADMINS=(abc|def|ghi)

Bei allen Kurzbefehlen, die für diese Benutzer zugänglich sein sollen, geben Sie dann users=ADMINS an. Wollen Sie später einen vierten Administrator jkl hinzufügen oder für diese Benutzergruppe einen neuen Befehl anlegen, ist nur an einer Stelle eine Änderung nötig – die Konfiguration wird durch Gruppen also übersichtlicher.

Weitere Features

Neben Benutzergruppen verwaltet Op auch mehrere Rechner (anhand ihrer Namen), so dass Sie mit einer zentralen Op-Konfigurationsdatei das Verhalten auf mehreren Maschinen festlegen und stets den Überblick darüber behalten, welche Rechte Sie auf welchen PCs vergeben haben.

Besonders flexibel ist das Programm auch beim Durchreichen von Umgebungsvariablen an das mit Root-Rechten gestartete Programm: Ohne weitere Argumente löscht Op alle Umgebungsvariablen, bevor es einen Befehl aufruft (weswegen auch in den Beispielen stets der volle Pfad zu Programmen notwendig war).

Die Option environment verhindert dies und reicht alle Variablen durch. Alternativ geben Sie manuell eine Auswahl der Variablen an, die erhalten bleiben sollen – diese schreiben Sie einfach in der Form $<§§I>Name<§§I> (also mit führendem Dollar-Zeichen) in den Eintrag. Ein Beispiel für den Umgang mit Variablen zeigt Listing 3.

test    /usr/bin/env;
        users=abc
        $LANG $TERM $SHELL $PATH

Der Kurzbefehl test ruft nur das Programm Env auf, das eine Liste aller Umgebungsvariablen ausgibt. Wie in Listing 3 gefordert, zeigt der Env-Befehl nur $LANG, $TERM, $SHELL und $PATH an; die restlichen Variablen zeigt er nicht.

abc@amd64:~> op test
LANG=de_DE@euro
TERM=xterm
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bi?
n:/usr/bin/X11:/usr/games

Fazit

Op ist ein mächtiges Werkzeug, das ähnliche Funktionen wie Sudo bietet, aber durch leichtere Konfiguration und auch simplere Aufrufe sowohl den Administrator als auch den Anwender entlastet – auch wenn es sich bei beiden um die gleiche Person handelt.