Türsteher
Admin-Rechte gezielt vergeben mit PolicyKit
Startrampe
Mit PolicyKit können Sie normalen Benutzern auch das Ausführen von Systemprogrammen gestatten. Dabei springt pkexec an die Stelle des bekannten sudo. Beispielsweise startet der Befehl
$ pkexec --user berta /usr/bin/apt-get
den Paketmanager im Rechtekontext der Benutzerin berta (siehe auch Kasten "Passwortfallen"). Die Anwendung läuft dabei grundsätzlich in einer minimalen und sicheren Umgebung. Dadurch lässt sich zwar kein fremder Programmcode einschleusen, umgekehrt ist es aber auch nicht möglich, X11-Programme unter einem anderen Benutzer zu starten.
Passwortfallen
Pkexec legt hinsichtlich der Passwortanfrage ein zwar völlig logisches, aber auf den ersten Blick etwas verwirrendes Verhalten an den Tag. Wenn Sie den Befehl
$ pkexec --user berta apt-get install gnuchess
eintippen, dann starten Sie selbst pkexec. PolicyKit fragt deshalb nach Ihrem Passwort – nicht etwa nach dem von Berta. Mangels Zugriffsrechten auf das Verzeichnis /var/lib/dpkg verweigert apt-get zudem die Installation. Um gnuchess als Benutzer berta einzuspielen, müssen Sie sich zunächst unter Bertas Namen anmelden und dann den Befehl
pkexec apt-get install gnuchess
absetzen. PolicyKit fragt jetzt nach Bertas Passwort, startet apt-get mit Root-Rechten und spielt gnuchess ein – vorausgesetzt, es existieren keine einschränkenden PolicyKit-Regeln.
Standardmäßig dürfen nur Administratoren ein Programm via pkexec starten, also alle in der Konfigurationsdatei /etc/polkit-1/localauthority.conf.d/60-meinekonfig.conf aufgeführten Personen. Um auch dem normalen Benutzer carlo das Starten von Programmen zu gestatten, erstellen Sie einfach eine neue Regel. Die entsprechende Aktion heißt hierbei org.freedesktop.policykit.exec (Listing 2).
Listing 2
[Programmausführung über pkexec erlauben] Identity=unix-user:carlo Action=org.freedesktop.policykit.exec ResultActive=yes ResultInactive=no ResultAny=no
Damit dürfte carlo jedoch sämtliche Programme über pkexec aufrufen. Soll er ausschließlich apt-get mit seinem Passwort starten dürfen, muss eine weitere, spezielle Konfigurationsdatei her.
Aktionsbündnis
PolicyKit kann nur dann eine Anfrage beantworten, wenn es die entsprechende Aktion kennt. Eine Anwendung muss folglich die von ihr angebotenen Systemfunktionen erst einmal PolicyKit mitteilen. Dazu verpackt sie die notwendigen Informationen in eine oder mehrere XML-Dateien, die sie wiederum im Unterverzeichnis /usr/share/polkit-1/actions parkt. Dort finden Sie beispielsweise in der Datei org.gome.clockapplet.mechanism.policy alle Aktionen des Gnome-Uhren-Applets, die eine Authentifizierung via PolicyKit verlangen.
Auch beim Start des Programms /usr/bin/apt-get handelt es sich um nichts weiter als eine Aktion. Um sie zu regulieren, müssen Sie hier eine weitere XML-Datei hinzufügen – deren Inhalt zeigt Listing 3.
Listing 3
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
<vendor>Linux New Media AG</vendor>
<vendor_url>http://www.linuxnewmedia.de</vendor_url>
<action id="de.linuxnewmedia.beispiel.run-apt-get">
<description>run apt-get</description>
<description xml:lang="de">apt-get ausführen</description>
<message>Authentication is required to run the program apt-get</message>
<message xml:lang="de">Sie müssen sich ausweisen, um das Programm apt-get ausführen zu können</message>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>auth_self_keep</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.exec.path">/usr/bin/apt-get</annotate>
</action>
</policyconfig>
Der Aufbau fällt etwas komplizierter aus als bei den bislang angesprochenen Konfigurationsdateien. Das kryptische Zeichengewirr am Anfang ist für jede XML-Datei Pflicht. Zwischen <vendor> und </vendor> steht der Herausgeber oder Entwickler, dessen Internetadresse in <vendor_url>. Als nächstes folgt die Definition der auszuführenden Aktion. Hinter <action id= erhält diese zunächst einen eindeutigen Namen, den PolicyKit auch als Action ID bezeichnet. Sie dürfen die Bezeichnung frei wählen, solange sie aus Zahlen, Kleinbuchstaben, Punkten und Bindestrichen besteht. Für gewöhnlich verwendet man die rückwärts gelesene URL des Herstellers und hängt dann den Namen der Aktion an.
Zwischen <description> und </description> folgt eine Beschreibung der Aktion, <description xml:lang="de"> nimmt die deutsche Übersetzung auf. Analog dürfen Sie Beschreibungen für weitere Sprachen hinterlegen, ein gutes Beispiel dafür liefert die Datei org.gome.clockapplet.mechanism.policy. Den Text innerhalb von message zeigt später das Fenster zur Passwortnachfrage an. Auch hier liefert <message xml:lang="de"> die deutsche Fassung. Der defaults-Abschnitt gibt vor, welche Rechte standardmäßig gelten. Mit
<allow_active>auth_admin</allow_active>
führt pkexec das Programm erst dann aus, wenn der Benutzer der aktiven Sitzung (allow_active) ein Administrator-Passwort eingegeben hat (auth_admin). Diese Einstellungen können Sie später mit einer .pkla-Datei in /etc/polkit-1/localauthority/50-local.d für jeden Benutzer individuell überschreiben.
Dementsprechend sind zwischen allow_active sämtliche Werte aus der Tabelle "PolicyKit: Berechtigungsarten" erlaubt. Analog kümmert sich allow_inactive um Anfragen von inaktiven Sitzungen (und entspricht somit ResultInactive), während sich allow_any (als Pendant zu ResultAny) nicht um die Herkunft schert. Abschließend folgt noch hinter <annotate key="org.freedesktop.policykit.exec.path"> der Pfad zum entsprechenden Programm, im Beispiel zum Paketmanager apt-get.
Die fertige Aktionsbeschreibung speichern Sie unter der Endung .policy. Der eigentliche Dateiname ist wieder unwichtig, in der Regel wählt man ihn genau so wie die Aktions-ID.



