Türsteher
Admin-Rechte gezielt vergeben mit PolicyKit
Extrawurst
Anschließend richten Sie im Unterverzeichnis /etc/polkit-1/localauthority/50-local.d eine spezielle (Ausnahme-)Regel für den Benutzer carlo ein (Listing 4). Damit darf carlo ab sofort das Programm apt-get per pkexec starten, ohne sein Passwort eingeben zu müssen (Abbildung 5). pkexec prüft allerdings nicht, welche Parameter ein Benutzer dem Programm mit auf den Weg gibt. carlo könnte im Beispiel folglich irgendein beliebiges (Schad-)Paket einspielen.
Listing 4
[Programm apt-get für Carlo freischalten] Identity=unix-user:carlo Action=de.linuxnewmedia.beispiel.run-apt-get ResultActive=yes ResultInactive=no ResultAny=no
Fazit
Mit PolicyKit lassen sich äußerst flexibel maßgeschneiderte Zugriffsprofile erstellen. Im Gegensatz zu su und sudo erhält der Anwender nicht gleich einen Freifahrtschein für die gesamte Anwendung, sondern bleibt auf einzelne (System-)Funktionen beschränkt. Zudem muss er nicht umständlich auf der Kommandozeile hantieren, sondern gibt höchsten sein Passwort preis.
In komplexen Szenarien fallen die Regeln jedoch schnell unübersichtlich aus, das Erstellen und Warten via Texteditor ist alles andere als komfortabel. Darüber hinaus setzt PolicyKit ein weiteres Rechtemanagement auf das von Linux. Selbst wenn Sie carlo den Start eines Programms mit PolicyKit verbieten, kann er es eventuell weiterhin direkt oder über sudo ausführen. Sie müssen folglich sowohl die Einstellungen von PolicyKit als auch die herkömmlichen Rechte im Blick behalten.
Nicht zuletzt müssen Entwickler PolicyKit explizit in ihren Anwendungen unterstützen, die Desktopsysteme einen Passwort-Bildschirm bereitstellen und die Distributionen PolicyKit konsequent einsetzen. Wie die (noch) aktuellen Fassungen von OpenSuse, Fedora und Ubuntu zeigen, besteht zumindest beim zuletzt genannten Punkt noch reichlich Aufholbedarf.
Infos
[1] PolicyKit: http://www.freedesktop.org/wiki/Software/PolicyKit



