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