polkitd
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
Ubuntu 24.04 Noble Numbat
Du möchtest den Artikel für eine weitere Ubuntu-Version testen? Mitarbeit im Wiki ist immer willkommen! Dazu sind die Hinweise zum Testen von Artikeln zu beachten.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
⚓︎ PolicyKit und, optional für Ubuntu Versionen vor 24.04: PolicyKit 0.105
Dieser Artikel behandelt den DAEMON polkitd aus der Werkzeugsammlung PolicyKit bzw. polkit in der bei Ubuntu ab Version 24.04 verwenden Fassung. Für frühere Versionen siehe Artikel PolicyKit 0.105[1].
Dieser Artikel setzt die Kenntnis des Übersichtsartikels[1] voraus, siehe dort für eine Beschreibung der Funktionsweise des Systems polkit und Erklärungen für spezifische Fachbegriffe wie "Client", "Subject", „privilegiertes Programm“ und „Authentifizierungsagent“.
Installation¶
Das Paket pokitd gehört zur Standardinstallation. Für weitere Details lese den Übersichtsartikel[1].
Bedienung¶
Der DAEMON polkitd
wird vom Init-System automatisch als Unit polkit.service
gestartet und bedarf normalerweise keiner Bedienung. Bei Bedarf kann man ihn mit den Standardbefehlen von systemctl steuern.
Der DAEMON liest die Dateien mit den Aktionen (= actions[1]) und Regeln (= rules[1]) und überwacht diese auch selber; dh. bei Änderungen werden diese Dateien automatisch erneut gelesen. Dafür bedarf es keinen Restart durch den Systemverwalter.
Dienstprogramme¶
Das Paket polkitd enthält auch die in eigenen Artikeln beschrieben Dienstprogramme pkaction
und pkcheck
.
Aktionen¶
Aktionen werden in der Regel nicht vom Anwender, sondern vom Autor eines privilegierten Programms[1] beschrieben. Eine wichtige Ausnahme von dieser Regel ist die Erstellung von speziellen Aktionen für den Wrapper pkexec.
Aktionen beschreiben¶
Aktionen werden in Textdateien mit XML-Format beschrieben. Jede Aktion wird identifiziert über eine eineindeutige AKTION-ID[1] nach dem Muster Namensraum.Kennung
, wobei sowohl Namensraum
als auch Kennung
nicht-leere Zeichenfolgen aus zulässigen ASCII-Zeichen darstellen, das sind die Buchstaben A-Z
und a-z
sowie die Ziffern 0-9
, der Punkt und der Bindestrich. Eine Datei kann eine oder mehrere Aktionen beschreiben, jedoch müssen alle Aktionen in einer Datei denselben Namensraum (namespace) teilen. Der Dateiname muss Namensraum.policy
lauten und die Datei muss in einem der folgenden Ordnern abgelegt werden:
/etc/polkit-1/actions/ ist vorgesehen für vom Administrator für das System erstellte Aktionen, die dauerhaft benutzt werden sollen.
/run/polkit-1/actions/ kann Aktionen enthalten, die nur für den aktuellen Systemstart gelten sollen. Das Verzeichnis /run/ wird bei jedem Systemstart neu erstellt.
/usr/local/share/polkit-1/actions/ ermöglicht die dauerhafte Änderung in den mit dem System gelieferten Aktionen ohne diese selbst zu ändern. Dazu kopiert man die Datei aus dem folgenden Ordner in diesen Ordner und ändert die Kopie.
/usr/share/polkit-1/actions/ enthält Aktionen, die mit dem System polkit geliefert werden oder vom Betriebssystem bzw. der Distribution stammen oder zu installierten Applikationen gehören. Man sollte selbst hier nichts ablegen oder ändern, weil eigene Eingriffe bei einem Update/Upgrade überschrieben werden können.
In der Regel existiert bei Ubuntu nur der zuletzt genannte Ordner. Sowohl Ordner als auch dort abgelegte Dateien müssen als Besitzer und Gruppe root
gehören und nur root
darf in diesen Ordnern Dateien erstellen und ändern können – wenn man selbst diese Ordner anlegt, muss man auch selbst die Rechte richtig setzen.
⚓︎ Beispiel (gekürzt): /usr/share/polkit-1/actions/org.freedesktop.policykit.policy
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD polkit Policy Configuration 1.0//EN" "http://www.freedesktop.org/software/polkit/policyconfig-1.dtd"> <!-- Policy definitions for core polkit actions. Copyright (c) 2008-2012 Red Hat, Inc. --> <policyconfig> <vendor>The polkit project</vendor> <vendor_url>http://www.freedesktop.org/wiki/Software/polkit/</vendor_url> <action id="org.freedesktop.policykit.exec"> <description>Run a program as another user</description> … <description xml:lang="de">Ein Programm als ein anderer Benutzer ausführen</description> … <message>Authentication is required to run a program as another user</message> … <message xml:lang="de">Legitimierung ist erforderlich, um ein Programm als ein anderer Benutzer auszuführen</message> … <defaults> <allow_any>auth_admin</allow_any> <allow_inactive>auth_admin</allow_inactive> <allow_active>auth_admin</allow_active> </defaults> </action> </policyconfig>
Die verfügbaren XML-Elemente beschreibt Tabelle 1. Die für die Funktion einer Aktion wichtigen Elemente sind fett gedruckt; alle anderen dienen zur Strukturierung des Objekts, zur Dokumentation oder zur Bedienerführung.
Tabelle 1: XML-Elemente für Aktionen | ||||
Vorgänger | XML-Element | Min/Max | Bemerkung | |
(Datei) | polkitconfig | 1 / 1 | ||
polkitkonfig | vendor | 0 / 1 | Dokumentation | |
vendor_url | 0 / 1 | Dokumentation | ||
icon_name | 0 / 1 | Bedienerführung | ||
action | 1 / ∞ | Attribut "id" muss angegeben werden. | ||
action | description | 0 / ∞ | Attribut "xml:lang" kann zur Lokalisierung angegeben werden. Dokumentation und Bedienerführung | |
message | 0 / ∞ | Attribut "xml:lang" kann zur Lokalisierung angegeben werden. Bedienerführung | ||
defaults | 1 / 1 | Darf nicht leer sein. | ||
annotate | 0 / ∞ | Siehe Tabelle 2. | ||
vendor | 0 / 1 | Überschreibt entsprechende Angabe auf höherer Ebene. | ||
vendor_url | 0 / 1 | |||
icon_name | 0 / 1 | |||
defaults | allow_any | 0 / 1 | Vorgabe für die benötigte Autorisierung, abhängig vom Typ der Sitzung (über Netzwerk oder lokal sowie aktiv oder inaktiv). Mögliche Werte siehe Tabelle 3. Diese Werte werden wirksam, wenn sie nicht durch Regeln übersteuert werden, vgl. Tabelle 4. | |
allow_inactive | 0 / 1 | |||
allow_active | 0 / 1 |
Aktionen sichten¶
Beschreibungen für Aktionen kann man sich auf der Ebene XML anschauen mit jedem Texteditor oder auch auf der Kommandozeile[2] mit einem Pager wie beispielsweise less:
less /usr/share/polkit-1/actions/org.freedesktop.policykit.policy
Beispielausgabe s.o.
Im Klartext lässt sich eine Aktion mit pkaction im Terminal lesen.
Aktion bearbeiten¶
Die Beschreibungen der Aktionen lassen sich grundsätzlich mit Root-Rechten[4] mittels Texteditor bearbeiten. Man sollte dies aber im Order /usr/share/polkit-1/actions/ vermeiden, da hier abgelegte Dateien beim Update/Upgrade überschrieben werden können. Statt einer direkten Bearbeitung kopiert man die Datei unter Beibehaltung ihres Namens in den Ordner /usr/local/share/polkit-1/actions/ und bearbeitet die Kopie. Solange man die AKTION-ID[1] nicht ändert, überlagert die unter /usr/local/share abgelegte Beschreibung die gleichnamige unter /usr/share.
Beispielsweise kann man so mit der Datei org.freedesktop.policykit.policy verfahren und dann in der Kopie "<allow_active>auth_admin</allow_active>"
ersetzen durch "<allow_active>auth_self</allow_active>"
. Dies bewirkt, dass jeder Benutzer bei der Benutzung von pkexec
nicht mehr nach dem Passwort eines Administrators (im Sinne polkit), sondern nach seinem eigenen gefragt wird – dh. jeder Benutzer kann eine Root-Shell starten und benutzen.
Aktion anlegen¶
Wenn man für pkexec eine Aktion definieren möchte, erstellt man eine Datei im Ordner /etc/polkit-1/actions/. In diesen Beschreibungen muss man das XML-Element annotate mit einem Attribut key
nach Tabelle 2 verwenden. Weiteres siehe Dokumentation.
Tabelle 2: Bekannte Schlüssel im XML-Element annotate | |
Attribut key= | Beschreibung |
org.freedesktop.policykit.exec.path | Wird vom Systemverwalter benutzt zur Erweiterung von pkexec um eine eigene Aktion. Inhalt des XML-Elements ist der vollständige Pfad zum ausführbaren Datei für die Aktion. |
org.freedesktop.policykit.exec.argv1 | Wird vom Systemverwalter benutzt zur Erweiterung von pkexec um eine eigene Aktion. Inhalt des XML-Elements ist eine beliebige Zeichenkette, der beim Aufruf eines Programms per pkexec dem Programm als erster Parameter mitzugeben ist. Beispielsweise gelten für eine Bearbeitung einer Datei mit dieser Zeichenkette als Namen dann die Einschränkungen dieser Aktion. |
org.freedesktop.policykit.exec.allow_gui | Wird vom Autor eines privilegierten Programms benutzt, um polkitd zu versichern, dass dieses privilegierte Programm gefahrlos auch in einer graphischen Umgebung gestartet werden darf. Inhalt des XML-Element ist ein boolescher Wert true oder false (Vorgabe). |
org.freedesktop.policykit.imply | Wird vom Autor eines privilegierten Programms benutzt. Inhalt des XML-Elements ist die ID einer anderen Aktion, auf der der Aufrufer bei erfolgreicher Authentifizierung für die aktuelle Aktion ebenfalls Zugriff erhält. |
org.freedesktop.policykit.owner | Wird vom Autor eines privilegierten Programms benutzt. Inhalt des XML-Elements ist eine Liste von Benutzern, die abfragen dürfen, ob andere Benutzer für diese Aktion autorisiert werden können. |
Regeln¶
Regeln werden vom Systemverwalter erstellt. Ubuntu bringt aber auch bereits selbst einen Regelsatz mit. Von polkitd ausgewertet werden Regeln in Dateien mit dem Suffix .rules
in bestimmten Ordnern:
/etc/polkit-1/rules.d/ ist vorgesehen zur Ablage von eigenen Regeln.
/usr/share/polkit-1/rules.d/ enthält Regeln des Betriebssystems, des Desktops und von installierten Applikationen.
Die Dateinamen sind beliebig, müssen aber mit dem Suffix .rules
enden und werden in Wörterbuchordnung ausgewertet – damit man dies selbst steuern kann, sollten die Dateinamen mit einer (ggf. mit führender 0
) zweistelligen Zahl beginnen. Bei gleichnamigen Dateien wird die Datei aus /etc vor der aus /usr sortiert und beide werden ausgewertet, sofern die unter /etc das nicht verhindert.
Ordner und Dateien müssen root
gehören und nur root
darf in den Ordnern Dateien anlegen/löschen oder schreiben/ändern.
⚓︎ Die Dateien enthalten Funktionen in JavaScript Version 5 mit Antworten für zwei unterschiedliche Fragen:
Welche Autorisierung ist im vorliegenden Fall erforderlich?
Wer ist im vorliegenden Fall Administrator (im Sinne polkit)?
Dabei bedeutet „im vorliegenden Fall“, dass polkitd die Funktionen mit aktuellem SUBJEKT[1] und aktueller AKTION[1] aufruft, deren Eigenschaften von der Funktion untersucht und für die Antwort (per return
) berücksichtigt werden können. Damit sind komplexe Aufgaben lösbar, beispielsweise:
Man kann bestimmte Benutzer nur für bestimmte Aktionen zum Administrator (im Sinne polkit) machen.
Man kann Aktionen nur unter bestimmten Umständen, z.B. zeitgesteuert erlauben.
Es ist ausdrücklich erlaubt, dass eine Funktion gar nichts zurück gibt, oder einen dazu lt. Tabelle 3 äquivalenten Wert. In solchen Fällen bleibt die Entscheidung offen und wird an die nächste Funktion delegiert. Bei einer anderen Rückgabe lt. Tabelle 3 von einer Funktion des ersten Typs ist die Entscheidung endgültig und weitere Funktionen werden gar nicht mehr aufgerufen.
Tabelle 3: Mögliche Rückgaben für Funktionen des ersten Typs | |||
XML | Skript | Beschreibung | |
no | polkit.Result.NO | Niemand (auch nicht root ) darf AKTION[1] ausführen. | |
yes | polkit.Result.YES | Jeder darf AKTION[1] ausführen. Niemand wird nach einem Passwort gefragt. | |
auth_self | polkit.Result.AUTH_SELF | Der Benutzer von SUBJEKT[1] darf AKTION[1] ausführen, sofern er sich erfolgreich authentifizieren kann – dh. er kennt sein Passwort und gibt es richtig ein. | |
auth_admin | polkit.Result.AUTH_ADMIN | Der Benutzer von SUBJEKT[1] darf AKTION[1] ausführen, sofern er sich erfolgreich als Administrator (im Sinne polkit) authentifizieren kann – dh. er kennt das Passwort eines Administrators und gibt es richtig ein. | |
auth_self_keep | polkit.Result.AUTH_SELF_KEEP | Wie die jeweilige Angabe ohne keep, zusätzlich wird aber das Ergebnis noch für eine kurze Zeit (5 min) erinnert und in einer hinsichtlich SUBJEKT[1] und AKTION[1] identischen Situation auf eine erneute Abfrage des Passworts verzichtet. | |
auth_admin_keep | polkit.Result.AUTH_ADMIN_KEEP | ||
polkit.Result.NOT_HANDLED | Die Entscheidung über die Autorisierung wird der nächsten aufgerufenen Funktion überlassen. Wenn es keine solche Funktion mehr gibt, gilt ein anwendbarer Wert aus der Beschreibung der Aktion. | ||
null | |||
undefined | |||
(gar nichts) |
Regeln auswerten¶
In jeder Situation, beschrieben durch SUBJEKT[1] inkl. Typ der Sitzung und angeforderter AKTION[1] prüft polkitd nacheinander bis zu 5 Kriterien nach Tabelle 4, bis eines ein definitives Ergebnis liefert. Die Prüfketten unterscheiden sich leicht je nach Typ der Sitzung.
Tabelle 4: Sitzungen und Autorisierung | ||||||
local | active | 1 | 2 | 3 | 4 | 5 |
true | true | gespeicherter Wert aus Regel | Wert aus Regel | allow_active aus Aktion | allow_any aus Aktion | no |
true | false | allow_inactive aus Aktion | ||||
false | → | → |
Die Attribute local
und active
von SUBJEKT[1] sind innerhalb der Regel abfragbar und die Regel kann abhängig von diesen Attributen ein unterschiedliches Ergebnis liefern.
polkitd prüft zunächst, ob für die Situation bereits aus kürzlich vorheriger Bearbeitung ein Ergebnis vorliegt und verwendet ein solches. Im anderen Fall werden
die relevanten Regeln nacheinander aufgerufen, bis eine ein definitives Ergebnis liefert. Dieses wird verwendet und weiter vorhandene Regeln werden nicht mehr aufgerufen. Im anderen Fall wird
für eine lokale Sitzung ein Wert aus der Beschreibung der Aktion verwendet, sofern ein solcher Wert existiert.
Im anderen Fall und ebenso bei einer Sitzung über Netzwerk wird der Wert für
allow_any
aus der Beschreibung der Aktion verwendet, sofern ein solcher Wert existiert.Wenn alle vorherigen Prüfungen nichts liefern, misslingt die Authentifizierung und das System verhält sich wie bei einem explizitem
no
.
Regel bearbeiten¶
Dateien mit Regeln im Ordner /usr/share/polkit-1/rules.d/ kann man grundsätzlich mit erweiterten Rechten[4] editieren, jedoch sollte man dies nicht tun, weil diese Dateien möglicherweise bei einem Update/Upgrade wieder ersetzt werden. Statt in diesem Ordner direkt zu ändern, kopiert man die Datei in den Ordner /etc/polkit-1/rules.d/ und ändert dort Inhalt und ggf. Dateinamen. Den Dateinamen muss man so wählen, dass die Kopie in Wörterbuchordnung vor dem Original sortiert wird. Den Inhalt dieser und ggf. weiterer Dateien muss man so gestalten, dass die Originaldatei gar nicht mehr ausgewertet wird – dazu sind die Rückgabewerte der Funktionen so zu wählen, dass keine Fälle mehr offen bleiben.
Jede Funktion beantwortet – möglicherweise nur für einige Fälle – entweder die erste oder zweite o.g. Frage. Mögliche Antworten auf die erste Frage siehe Tabelle 3 und für die zweite Frage ist immer ein Array mit Elementen aus Tabelle 5 zurück zu geben.
In den Dateien müssen die definierten Funktionen mit Hilfe der von polkit bereit gestellten Prozeduren
addRule()
für eine Funktion mit einer Antwort auf die Frage: „Welche Autorisierung ist im vorliegenden Fall erforderlich?“addAdminRule()
für eine Funktion mit einer Antwort auf die Frage: „Wer ist im vorliegenden Fall Administrator (im Sinne polkit)?“
an polkitd übergeben werden.
Tabelle 5: Mögliche Rückgaben für Funktionen des zweiten Typs | |
Element | Beschreibung und Beispiel |
unix-user:BENUTZER | BENUTZER steht für einen Benutzernamen, standardmäßig aus der Datei /etc/passwd. Man kann den Benutzernamen oder dessen numerische Kennung (uid) verwenden. Beispiele: unix-user:root, unix-user:1000 |
unix-group:GRUPPE | GRUPPE steht für den Namen einer Gruppe, standardmäßig aus der Datei /etc/group. Man kann den Gruppennamen oder dessen numerische Kennung (gid) verwenden. Beispiele: unix-group:sudo |
unix-netgroup:NETGROUP | NETGROUP steht für den Namen einer netgroup aus der Datei /etc/netgroup. → Externe Verweise |
Hinweis:
Man kann durchaus mehrere Administratoren (im Sinne polkit) definieren. Das nutzt aber in der Praxis nichts, denn die Authentifizierungsagenten erlauben keine Auswahl des Benutzers. Es wird immer nach dem Passwort des ersten gefundenen Benutzers gefragt. Die Entwickler bewerten dies unterschiedlich als Fehler oder als sinnvollen Schutz der Anwender vor Überforderung durch zu komplizierte Funktionalität.
Regel erstellen¶
Eine Datei für eigene Regeln erstellt man mit erweiterten Rechten[4] im Ordner /etc/polkit-1/rules.d/. Der Dateiname ist so zu wählen, dass die Funktionen an der richtigen Stelle im gesamten Regelwerk aufgerufen werden. Bearbeitung der Datei wie vorstehend.
Beispiele für Regeldateien¶
Standard-Regel für Administratoren¶
Die Datei /usr/share/polkit-1/rules.d/50-default.rules enthält die von polkit selbst vorgesehene Definition eines Administrators:
function(action, subject) { return ["unix-group:sudo"] }
Somit wäre ein Administrator (im Sinne polkit) jemand, der zur Gruppe sudo
gehört und damit bereits ein Administrator im Sinn Systemverwalter ist. Diese Regel wird allerdings bei Ubuntu wegen der vorgeschalteten Regel in nächsten Abschnitt niemals wirksam.
Ubuntu-Regel für Administratoren¶
Die Datei /usr/share/polkit-1/rules.d/49-ubuntu-admin.rules enthält:
function(action, subject) { return ["unix-group:sudo", "unix-group:admin"] }
Diese Funktion entscheidet über alle Fälle und ist daher abschließend. Hier wird eine Gruppe admin
genannt, deren Mitglieder alternativ auch als Administrator (im Sinne polkit) arbeiten dürfen. Allerdings existiert bei aktuellen Ubuntu-Versionen diese Gruppe gar nicht mehr (früher schon), so dass sich in der Praxis keine Änderung des Standardverhaltens ergibt. Möglicherweise ist diese Vorgehensweise ein überflüssiges veraltetes Relikt.
Eigene Regel für Administrator¶
Da die mit Ubuntu ausgelieferte Regel sowieso nicht wie beabsichtigt funktioniert, dafür aber unnötig Sicherheitslöcher öffnet, sollte man sie durch eine klare Regel ersetzen: „Administrator (im Sinne polkit) ist ein (und nur ein) bestimmter Benutzer!“ Dazu erstellt man als root[4] eine nur durch root änderbare Datei:
sudo touch /etc/polkit-1/rules.d/00-ubuntuusers-de.SATAN.rules sudo chown root:root $_ sudo chmod 644 $_ echo 'addAdminRule( function(a, s) { return ["unix-user:NNN"] } ); ' | sudo tee $_
Dabei ist anstelle NNN die numerische uid eines existierenden Benutzers einzusetzen, sinnvolle Werte sind:
0
, dann muss man aber auch root die Anmeldung erlauben und ihm ein Passwort geben.1000
, das ist der bei der Installation automatisch eingerichtete Hauptbenutzer.666
(oder andere freie Benutzer-ID), dann muss man diesen Benutzer aber auch, z.B. mit adduser einrichten:sudo adduser --home /nonexistent --shell /user/sbin/nologin --uid 666 --gid 65534 --allow-bad-names SATAN
Dieser Benutzer darf sich selbst nicht anmelden und benötigt kein Home-Verzeichnis; das Konto besteht sozusagen nur aus einem Passwort. Selbstverständlich kann man den Benutzernamen beliebig wählen.
Revival Windows 95¶
Eine Datei wie die folgende /etc/polkit-1/rules.d/00-anarchie.rules sorgt dafür, dass ohne Passwortabfrage jeder alles darf:
addRule( function (a, s) { return polkit.Result.YES } );
Dieses Beispiel soll nur zur Warnung und Anschauung dienen; seiner praktischen Anwendung wird dringend widerraten!
Dokumentation¶
Die Programme polkitd
, pkaction
und pkcheck
haben jeweils eine eigene Manpage:
man polkitd man pkaction man pkcheck
Hinweise zu Aktionen und Regeln findet man in der übergeordneten Manpage und in der zu pkexec
:
man polkit man pkexec
Man sollte die auf dem eigenen Rechner installierten, zur konkret verwendeten Version von polkit passenden Manpages bevorzugen.
Links¶
Externe Verweise
Netgroups lokal mit NFS und Samba nutzen 🇩🇪 – bei ProLinux.de 2005