 "AA_tuersteher_PO-21680-Fotolia_GordonBussiek.jpg")
Unter Linux sind die Machtverhältnisse klar geregelt: Ausschließlich der allmächtige Nutzer root darf die Systemeinstellungen verstellen, normale Anwender bleiben auf ihrem Desktop eingesperrt. Im Alltag erweist sich diese Zweiteilung oft als hinderlich, beispielsweise wenn man nur mal eben einen USB-Stick einbinden oder die falsch tickende Systemuhr stellen möchte. Teilen sich mehrere Benutzer einen PC, muss dann sogar jedes Mal der menschliche root anrücken.
Abhilfe verspricht das noch relativ junge Projekt PolicyKit [1]. Es bietet eine unabhängige Rechteverwaltung, die ganz ähnlich wie die Telefonauskunft funktioniert: Linux-Programme können dort anrufen und nachfragen, ob ein Benutzer eine bestimmte Systemfunktion ausführen darf.
Fräulein vom Amt
Genau das passiert beispielsweise auch unter Ubuntu, wenn Sie die Systemuhr stellen möchten. Bevor das ziemlich zugeknöpfte Fenster hinter System | Systemverwaltung | Datum und Uhrzeit irgendwelche Änderungen zulässt, ist zunächst ein Klick auf das Schloss-Symbol fällig. Damit fragen die Zeit- und Datumseinstellungen bei PolicyKit an, ob Sie überhaupt berechtigt sind, die Uhr einzustellen.
PolicyKit beantwortet diese Frage mit einem Blick in sein Regelwerk. Dort steht geschrieben, dass Sie die Zeit nur dann ändern dürfen, wenn Sie zur Gruppe der Administratoren gehören und sich mit Ihrem Passwort ausweisen können. PolicyKit bittet daraufhin den Desktopmanager Gnome, das Passwort abzufragen. Der leistet umgehend Folge und öffnet das Fenster aus Abbildung 1. Sobald PolicyKit alle Informationen beisammen hat, gibt es den Zeit- und Datumseinstellungen grünes Licht, woraufhin diese wiederum sämtliche Funktionen freischalten.
Abbildung 1: Das Freischalten der Uhreneinstellungen erfolgt unter Gnome über PolicyKit.
Auf diese Weise lassen sich mit PolicyKit gezielt Rechte erteilen oder entziehen. Beispielsweise könnte man dem Benutzer carlo ausnahmsweise gestatten, an der Uhr zu drehen – alle anderen Systemfunktionen blieben für ihn weiterhin tabu. Im Gegensatz zu su oder sudo erhalten die beteiligten Anwendungen dabei keinerlei Root-Rechte. carlo könnte folglich über das Uhren-Fenster weder die Zeitzone ändern, noch auf andere Teile des Systems zugreifen.
Unter der Haube
Da PolicyKit selbst aus mehreren Einzelteilen besteht, löst eine Anfrage immer gleich eine kleine Kettenreaktion aus. Zu Beginn ruft ein unprivilegiertes Programm, der sogenannte Client, eine Funktion eines privilegieren Programms auf, des "Mechanism". Beispielsweise könnte ein Desktop-Applet (der Client) versuchen, den Rechner via DeviceKit (der Mechanism) in einen Energiesparmodus zu versetzen.
Der Mechanism vergewissert sich jetzt bei PolicyKit, ob der Client diese Aktion auslösen darf. Dazu schickt er eine Anfrage an den D-Bus-Service org.freedesktop.PolicyKit1. D-Bus seinerseits startet daraufhin automatisch den PolicyKit-Daemon polkitd. Der prüft anhand seiner Regeln, ob der Client vertrauenswürdig ist. Sofern dies die Eingabe eines Passworts erfordert, bittet er über den D-Bus die Desktopumgebung, einen Authentication Agent zu starten. Dieser besteht in der Regel aus einem kleinen Fenster, das vom Benutzer ein Passwort einfordert. Wie der Authentication Agent genau auszusehen hat, bestimmen die Entwickler der Desktopumgebung.
Erhält der Mechanism schließlich von PolicyKit über den D-Bus eine positive Rückmeldung, führt er die entsprechende Funktion aus, andernfalls bricht er mit einer Fehlermeldung ab. Abbildung 2 veranschaulicht den kompletten Ablauf.
Abbildung 2: Zunächst aktiviert der Client einen Systemdienst (1). Dieser fragt dann via D-Bus PolicyKit um Erlaubnis (2), das wiederum bei Bedarf ein Passwort vom Nutzer einfordert (3).
Zahlenrätsel
Die schöne neue PolicyKit-Welt besitzt allerdings auch ein paar Makel. So müssen sowohl die Anwendungen als auch die Distributionen PolicyKit unterstützen. Einigermaßen flächendeckend ist das im Moment nur unter Ubuntu der Fall. OpenSuse 11.2 und Fedora 12 verlangen für die meisten Systemeinstellungen weiterhin das Root-Passwort. In OpenSuse dient PolicyKit lediglich dazu, die Software-Aktualisierungen durch einen beliebigen Benutzer einspielen zu lassen.
Darüber hinaus wurde das System mit Version 0.9.1 komplett umgekrempelt, die neueren PolicyKit-Fassungen arbeiten nicht mehr abwärtskompatibel. Folglich mussten erst alle Entwickler ihre darauf basiereren Anwendungen anpassen oder umschreiben. Die Distributionen greifen deshalb teilweise zur Holzhammermethode und bringen sowohl eine alte als auch die aktuelle Version mit. Letztere erhält zur besseren Unterscheidung häufig den inoffiziellen Namen PolicyKit-1 oder kurz polkit-1.
Mit ihr stellt auch der grafische Rechteeditor aus Abbildung 3 nur noch Makulatur dar. Er funktioniert ausschließlich unter einem alten PolicyKit bis einschließlich Version 0.9.0. Wer in die Rechtevergabe eingreifen möchte, muss derzeit wohl oder übel zum guten alten Texteditor greifen. Doch das ist weniger aufwändig, als es im ersten Moment klingt.
Abbildung 3: Dieser komfortable Rechteeditor funktioniert nur bis zur PolicyKit-Version 0.9.0.
Einem Freund empfehlen
