Simon, Thanks, that is very useful.
Andrew, On Tue, Dec 17, 2024 at 10:53:39AM +0000, Simon McVittie wrote: > check that the desktop environment is actually launching a polkit agent and > registering it with polkitd on the D-Bus system bus. I omitted to check for this in the basic steps I gave you. On my working setup, polkitd is running test@DebianUnstable:~$ pgrep -a polkitd 3123 /usr/lib/polkit-1/polkitd --no-debug and registered on the bus test@DebianUnstable:~$ busctl|grep -i polkit :1.62 3123 polkitd polkitd :1.62 - - - org.freedesktop.PolicyKit1 3123 polkitd polkitd :1.62 - - - After killing it test@DebianUnstable:~$ sudo pkill polkitd test@DebianUnstable:~$ pgrep -a polkitd test@DebianUnstable:~$ busctl|grep -i polkit it is legacy activated when required test@DebianUnstable:~$ pkexec id ==== AUTHENTICATING FOR org.freedesktop.policykit.exec ==== Authentication is needed to run `/usr/bin/id' as the super user Authenticating as: Test User,,, (test) Password: ==== AUTHENTICATION COMPLETE ==== uid=0(root) gid=0(root) groups=0(root) test@DebianUnstable:~$ pgrep -a polkitd 3344 /usr/lib/polkit-1/polkitd --no-debug test@DebianUnstable:~$ busctl|grep -i polkit :1.68 3344 polkitd polkitd :1.68 - - - org.freedesktop.PolicyKit1 3344 polkitd polkitd :1.68 - - - Can you verify polkitd is running correctly and registered? Thanks Mark > > You can disable the internal agent for debugging by running a command like: > > pkexec --disable-internal-agent id > > which would be closer to an apples-to-apples comparison with other polkit > clients. If this fails with the same error message that you have seen for > other privileged operations, then the problem is that your polkit agent > is absent or not correctly registered with polkitd. > > Command-line tools like pkexec and flatpak often provide a fallback > agent on the terminal like this, so that they can be run from a non-GUI > session. GUI tools essentially never do: they expect to be run in a > desktop environment session where there is already a working polkit agent. > > I am not familiar with XFCE, but I believe it is meant to include a polkit > agent of some sort? I can't find a particularly obvious candidate among > the packages that depend on libpolkit-agent-1-0 or provide > polkit-1-auth-agent, though. It might be helpful to install a standalone > polkit agent (perhaps lxpolkit or mate-polkit) and see what happens if you > run it manually before triggering a privileged operation. > > polkit agents are similar to o.fd.Notification implementations in > that there is a de facto assumption that any "complete" desktop > environment should provide one. Some desktop environments include an > integrated polkit agent that is part of the desktop shell (examples: > budgie-core, cinnamon, gnome-shell, gnome-flashback, phosh), some have > a dependency on a desktop-specific standalone agent that is hopefully > started automatically as part of the desktop environment (examples: > KDE Plasma/polkit-kde-agent-1, UKUI/ukui-polkit, LXDE/lxpolkit, > LXQT/lxqt-policykit, MATE/mate-polkit), and environments that are more > like a kit of parts to build your own desktop environment tend to not > include one and assume that the user will do their own setup. I had > hoped that XFCE would be in the first or second categories. > > Historically the polkit agent of last resort was policykit-1-gnome (which > was the one that was used in GNOME 2), but that one is unmaintained > upstream (a concerning situation for a security-critical component!) and > no longer accepts bug reports or merge requests, so the polkit maintainers > are trying to arrange for it not to be included in trixie (#990271). > Please do not rely on policykit-1-gnome. If it is the most suitable polkit > agent for XFCE, then the XFCE team will need to fork it and become the new > upstream maintainers of the fork. > > If you suspect that systemd vs. not-systemd is part of the problem here: > some desktop environments use `systemd --user` for part of their session > startup, and might have different behaviour on less-tested fallback code > paths (or just not work at all) without it. I know that GNOME and > KDE Plasma both make some use of `systemd --user` for session startup; > I don't know whether XFCE does, but that might be another thing to look at. > An apples-to-apples comparison of two VMs that have the same package > set and desktop environment, except that one has libpam-systemd (+ > dependencies) and the other has libpam-elogind (+ dependencies), might > be a helpful debugging step. > > Another helpful debugging step would be to find a desktop environment that > definitely does have a working polkit agent when installed with systemd > (perhaps LXDE), and try installing that same desktop environment with > sysvinit/elogind for an apples-to-apples comparison. > > > However, all 'desktop' polkit integration appears non-functional > > (reboot/hibernate/shutdown in lightdm an xfce4, pcscd mount etc...). The > > DBus > > error is InteractiveAuthorizationRequired. > > The documented meaning of that error is: the message requesting a > privileged action did not have the flag > DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION set, but something > (in practice polkit) had a policy that would have required it to carry > out interactive authorization, so the D-Bus service (lightdm or whatever) > is making the request fail in order to get a result back to the caller > promptly. The intention is that callers set > DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION if they are willing > to wait, potentially for several minutes, for a user to respond to a > prompt. > > However, it's possible that polkitd or some other relevant component > might be reusing that error code to indicate "my policy told me to > carry out interactive prompting, but I can't find an agent to do the > actual prompting, so I'm denying the request". > > smcv
