pkexec¶

Dieser Befehl erfüllt grundsätzlich die gleiche Aufgabe wie sudo, d.h. ein Programm wird mit Rechten eines anderen Nutzers - inklusive Root-Rechten^[4] - ausgeführt, jedoch werden die Regeln und Aktionen beachtet, und somit ist ist eine Rechtesteuerung selektiver bzw. feingranularer als mit sudo möglich.

Die allgemeine Syntax lautet^[2]:

pkexec [OPTIONen] PROGRAMMNAME 

Wird keine Option angegeben, wird PROGRAMMNAME als root ausgeführt. Dazu muss man aus Sicht vom PolicyKit keine (!) Root-Rechte auf dem System haben, man wird allerdings entsprechend den Regeln nach einem Passwort gefragt, und zwar standardmäßig nach dem Passwort des ersten Benutzers in der Gruppe sudo.

Mit der OPTION -u kann man PROGRAMMNAME aber auch mit den Rechten eines anderen Benutzers ausführen. So würde z.B.

pkexec -u otto PROGRAMMNAME 

PROGRAMMNAME als Nutzer otto ausführen.

Eine Root-Shell^[4] erhält man z.B. mit dem Befehl

pkexec bash -l 

Weitere Details lese auch im Artikel PolicyKit/pkexec zu neueren, aber in der Bedienung weitgehend kompatiblen Versionen.

pkaction¶

Hiermit können hinterlegte Aktionen gut lesbar angezeigt werden.

Der Aufruf

pkaction 

listet einfach die Namen aller Aktionen. Fügt man die Option --verbose hinzu, erhält man detailliertere Informationen zu jeder Aktion.

Der Befehl

pkaction --action-id com.ubuntu.pkexec.gedit --verbose 

zeigt nur Informationen für die Aktion mit der ID com.ubuntu.pkexec.gedit.

Weitere Details lese auch im Artikel PolicyKit/pkaction zu neueren, in der Bedienung kompatiblen Versionen.

pkcheck¶

Siehe Artikel PolicyKit/pkcheck zu neueren, aber in der Bedienung kompatiblen Versionen.

⚓︎

Regeln bearbeiten¶

Über Regeln können zusätzliche Rechte für Nutzer und Gruppen für verschiedene Aktionen vergeben werde.

Dazu arbeitet man im Terminal^[2] mit Root-Rechten^[4] und legt ggf. eine neue Datei an:

sudo touch /etc/polkit-1/localauthority/50-local.d/99-gparted-otto.pkla 

Diese Datei bearbeitet man mit einem Editor^[3]; der folgende Inhalt würde z.B. dem Nutzer "otto" erlauben, GParted per pkexec auszuführen, wobei das Password von otto abgefragt wird:

1
2
3
4
5
6

[extra permissions for gparted for user otto]
Identity=unix-user:otto
Action=com.ubuntu.pkexec.gparted
ResultInactive=no
ResultActive=auth_self
ResultAny=no

Die erste Zeile ist eine Kapitelüberschrift in einer INI-Datei, also ein in Klammern [] stehender beliebiger, aber einmaliger Text. Die 2. Zeile legt fest, für wen die Regel gilt; anstatt unix-user kann man über unix-group die Regel einer Gruppe zuweisen. Mehrere Benutzer können so angegeben werden: Identity=unix-user:otto;unix-user:susi. Die 3. Zeile legt fest, für welche Aktion die Regel gilt. Die Zeilen mit Result… bestimmen, was in verschiedenen Situationen geschehen soll:

• ResultActive gilt für die lokale aktive Sitzung, in der das Passwort des Benutzers erfragt werden soll.

• ResultInactive gilt für eine lokale, nicht aktive Sitzung, und

• ResultAny gilt für eine nicht-lokale Sitzung; no bedeutet ein nicht zu umgehendes Verbot der Aktion.

Eine weitergehende Erklärung zu Regeln liefert die Dokumentation.

Root-Rechte über PolicyKit¶

Wer einen Root-Account aktiviert hat (siehe Artikel sudo/Konfiguration (Abschnitt „Root-Passwort-einrichten“)) und bei sudo mit der targetpw Option eingestellt hat, dass das Root-Passwort statt wie sonst bei Ubuntu üblich das Benutzer-Passwort eingegeben werden muss, möchte dies auch für PolicyKit so haben. Das geht beispielsweise durch eine Konfigurationsdatei /etc/polkit-1/localauthority.conf.d/60-root.conf mit folgendem Inhalt:

[Configuration]
AdminIdentities=unix-user:0

pkexec startet Programm mit grafischer Oberfläche nicht¶

Das ist normalerweise genau so vorgesehen, weil der Zugriff eines fremden Benutzers F auf die grafische Oberfläche des anderen Benutzers B schwere Verwüstungen im Home-Verzeichnis von B anrichten kann, wodurch sogar die spätere Anmeldung von B scheitern kann. Das gilt erst recht, wenn der fremde Benutzer root ist.

Das Programm pkexec führt daher standardmäßig keine Programme aus, welche eine grafische Oberfläche benötigen. Beispielsweise scheitert der Aufruf

pkexec gedit 

mit einer Fehlermeldung. Dies liegt daran, dass in der Umgebung des fremden Benutzers die für grafische Programme notwendigen Umgebungsvariablen DISPLAY und XAUTHORITY des aufrufenden Benutzers nicht verfügbar sind.

Für solche grafischen Programme, die bekanntermaßen trotz Zugriff auf ein fremdes Home-Verzeichnis kein Chaos in diesem anrichten, gibt es 3 Möglichkeiten für einen erfolgreichen Aufruf mit pkexec:

1. Der Programmautor kann seine Software intern absichern und eine spezielle Beschreibung einer Aktion mitliefern, die polkitd über diese Absicherung informiert. Die grafischen Programme Synaptic und GParted gehen beispielsweise diesen Weg.

2. Der Systemverwalter^[5] kann für ein bestimmtes Programm anstelle des Programmautors eine solche Beschreibung einer Aktion erstellen und in dem von ihm betreuten System ablegen. Das sollte man nur dann tun, wenn man den Programmcode des grafischen Programms kennt und selber beurteilen kann, dass es kein Chaos in fremden Home-Verzeichnissen anrichtet. Diese Weg wird hier anschließend am Beispiel von gedit beschrieben, was sich aber eigentlich nicht für diesen Weg eignet. Von einer Anwendung wird daher abgeraten.

3. Der Anwender kann beim Aufruf die benötigten Umgebungsvariablen mitliefern. Das funktioniert technisch nur in einer auf Xorg basierenden Umgebung, und es erfordert beim Anwender entweder umfangreiche detaillierte Kenntnisse über das aufzurufende Programm oder fehlende Vernunft und fehlendes Verantwortungsbewusstsein.

Für die Wege 1 und 2 muss eine Datei mit einer Beschreibung einer Aktion angelegt werden^[3][4]. Dabei müssen die im Anschnitt Sicherheit genannten technischen Anforderungen gelten. Für gedit könnte der Inhalt so aussehen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

<?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>

  <action id="com.ubuntu.pkexec.gedit">
    <message>Authentication is required to run the gedit Editor</message>
    <icon_name>gedit</icon_name>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/gedit</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
  </action>

</policyconfig>

Nach dem Anlegen ist die Aktion direkt aktiv, das System muss nicht neu gestartet werden.

Der Aufbau der Datei ist weitestgehend logisch und selbsterklärend. Mit Dateien nach dem gleichen Schema können auch andere Programme mit grafischer Oberfläche via pkexec gestartet werden. Anzupassen sind jeweils die Zeilen 7, 8, 9 und 15. Die Zeile 16 ist die Zeile, die den Zugriff auf die grafische Oberfläche erlaubt.

Weiterführende Erklärung findet man in der Dokumentation.

Für den 3. Weg ist der Aufruf von pkexec:

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY PROGRAMMNAME 

PROGRAMMNAME muss durch das gewünscht Programm ersetzt werden, also z.B. gedit. Der Aufruf funktioniert so auch, wenn für PROGRAMMNAME keine Aktion angelegt ist.