PolicyKit und hidepid
…sind keine gute Kombination und haben mich kürzlich doch sehr irritiert. Doch der Reihe nach.
Nachdem der überwiegende Teil meiner Server bereits mit Gentoo läuft, habe ich mir vor ein paar Wochen vorgenommen, Gentoo auch einmal auf einem Desktop (respektive Laptop) einzusetzen, natürlich erst (mehrfach) in verschiedenen VMs. Um die „Grundinstallation“ des Basis-Systems zu vereinfachen, habe ich dazu ein von mir (weiter)entwickeltes Skript genutzt, welches ich auch für meine Server einsetze.
Die Grundinstallation selbst war damit auch jeweils recht zügig abgeschlossen, dank des großartigen Gentoo-Wikis war auch die Installation einer Desktopumgebung (Xfce und MATE) nach etwas Recherche kein größeres Problem.
So weit, so gut – fast jedenfalls.
Problematisch waren allerdings alle Anwendungen bzw. „Vorgänge“ innerhalb der jeweiligen Desktopumgebung, die zur Ausführung erweiterte Rechte benötigen. Zuerst ist mir das bei NetworkManager aufgefallen, der sich beharrlich weigerte, neue Verbindungen aufzubauen; alle Vorgänge wurden mit der Fehlermeldung Not authorized to control networking
abgewiesen. Im Log-File des Xorg-Servers fanden sich Einträge, die auf Probleme mit der Kommunikation zu dbus
hindeuteten.
Da mir zunächst nicht bewusst war, dass neben NetworkManager auch weitere Anwendungen von dem Problem betroffen waren, führte ich das fehlerhafte Verhalten zunächst auf NetworkManager selbst zurück. Hierzu fand ich auf launchpad.net auch einen entsprechenden Bug-Report, der meiner Einschätzung nach auch in meinem Fall zutraf, zumal der beschriebene Workaround zur Deaktivierung der PolicyKit-Authentifizierung im NetworkManager auch funktioniert hat.
Hier muss ich kurz ein wenig ausholen. Das Gespann aus policykit
, consolekit
und dbus
wird dazu genutzt, Anwendungen bei Bedarf mit erweiterten Rechten auszuführen und stellt das Pendant zum (mittlerweile weitgehend obsoleten) gksu
dar. Hauptsächlich ist dies für systemnahe Anwendungen (wie besagten NetworkManager) relevant, damit auch „normale“ Systembenutzer Änderungen an Systemeinstellungen vornehmen können, die (eigentlich) root vorbehalten sind – wie etwa das Ändern der Netzwerk-Konfiguration.
Die Rechte-Erweiterung funktioniert dabei vereinfacht gesagt folgendermaßen: Zunächst meldet die Anwendung über dbus
an policykit
, dass sie erweiterte Rechte benötigt. policykit
prüft dann anhand vorab definierter Regeln, ob sowohl der anfordernde Benutzer als auch die Anwendung selbst hierzu berechtigt sind. Bei erfolgreicher Authentifizierung meldet policykit
dies wieder über dbus
an die Anwendung zurück.
Nach „erfolgreicher“ Umsetzung des NetworkManager-Workarounds musste ich allerdings feststellen, dass auch weitere Anwendungen betroffen waren – konkret ging es dabei um die Energiespareinstellungen in Xfce, die nicht zur Verfügung standen. Das Problem konnte also nicht am NetworkManager, sondern vielmehr an meiner Konfiguration von policykit
selbst liegen. Mehrere Versuche, eventuell fehlende Session-Parameter mit diversen Anpassungen an lightdm
und der .xinitrc
blieben erfolglos.
Später habe ich dann in den relevanten Logfiles Einträge gefunden, die darauf schließen ließen, dass einige Dateien unterhalb von /proc
von policykit
nicht gelesen werden konnten – ein neuer Anhaltspunkt. (Es hat sich übrigens herausgestellt, dass die Fehlermeldungen bzgl. /proc
schon bei meinen ersten Versuchen geloggt wurden – ich habe sie wohl schlichtweg übersehen.)
Bei meinen weiteren Recherchen bin ich dann auf diesen Foren-Beitrag gestoßen:
Could just as well be a configuration issue, like what would probably happen if you’d mount /proc with the hidepid option. But without any details given, I’d say just mark it as [whatever].
hidepid? Natürlich! Sehr hilfreich, wenn es darum geht, Prozesse zwischen einzelnen Systembenutzern abzuschotten beziehungsweise „auszublenden“.
Und Bestandteil meines Standard-Setups.
Damit ergibt natürlich auch die Fehlermeldung bzgl. „fehlender“ Dateien bzw. Pfade unterhalb von /proc auf einmal Sinn: policykit läuft aus Sicherheitsgründen nicht als root, sondern als eigener Systembenutzer – und damit werden die anfordernden Anwendungen für policykit unsichtbar – ein Prozess des Benutzers foo
mit der PID 12345 existiert für den policykit-Benutzer schlichtweg nicht – demzufolge kann policykit hier natürlich auch keine sinnvolle Rückmeldung oder gar Authorisierung geben.
Logisch, oder?