Bug#1076728: elogind: privileged operation with polkit fails

[tito]

On Tue, 17 Dec 2024 10:53:39 +0000
Simon McVittie <smcv at debian.org> wrote:

> Context for XFCE and polkitd maintainers (cc'd): a user of XFCE on a
> sysvinit/elogind system has found that authorizing privileged operations
> via polkit is not working as intended. I'm not at all sure that this is
> actually an elogind problem: it might be a result of XFCE not obviously
> containing a polkit agent (the component that does the actual prompting).
> 
> On Tue, 17 Dec 2024 at 08:24:39 +0000, Mark Hindley wrote:
> > Basic testing of the libpam-elogind stack appears OK: loginctl reports a
> > registered session and 'pkexec id' prompts for a password and reports root.
> 
> An important difference between pkexec and most other polkit clients
> is that pkexec has its own minimal built-in polkit agent, which is
> used as a fallback if the desktop environment has not registered one
> with polkitd. Is the prompt inline on the terminal, or is it a separate
> window? And is the UI the same for the same desktop environment installed
> on a test system (perhaps a VM) that was booted with systemd and has a
> working `systemd --user`?
> 
> If the prompt was inline on the terminal, check that the desktop
> environment is actually launching a polkit agent and registering it with
> polkitd on the D-Bus system bus.
> 
> 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
> 

Hi,
I'm on a sysvinit/elogind system too and have KDE and xfce4 installed.
I use xfce4 as daily driver and everything works as expected.
I have these polkit stuff installed:

apt list *polkit* | grep installed

gir1.2-polkit-1.0/stable,now 122-3devuan2 amd64 [installed,automatic]
libpolkit-agent-1-0/stable,now 122-3devuan2 amd64 [installed,automatic]
libpolkit-gobject-1-0/stable,now 122-3devuan2 all [installed]
libpolkit-gobject-elogind-1-0/stable,now 122-3devuan2 amd64 [installed]
libpolkit-qt5-1-1/stable,now 0.114.0-2 amd64 [installed,automatic]
polkit-kde-agent-1/stable,now 4:5.27.5-2 amd64 [installed]
polkitd-pkla/stable,now 122-3devuan2 amd64 [installed,automatic]
polkitd/stable,now 122-3devuan2 amd64 [installed,automatic]

when a xfce4 session is running I see:

 ps ax | grep polkit
 5660 ?        Sl     0:00 /usr/lib/polkit-1/polkitd --no-debug
 5829 ?        Sl     0:00 /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1

You can find this polkit agent in the xfce4 -> Settings -> session and startup config
menu but it is not user editable, in fact it is autostarted in:

/etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop

--------snip-------
[Desktop Entry]
Name=PolicyKit Authentication Agen
# some more translations here
Exec=/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
Terminal=false
Type=Application
Categories=
NoDisplay=true
OnlyShowIn=XFCE;Unity;X-Cinnamon;
----------------- 

So I presume it is started early in the X startup process
probably by the login manager itself (sddm in my case).

So check if you have this files in place.
Hope this helps.
Ciao
Tito

P.S.:  I recall that I used the Kde polkit agent for sometime
in the past and it mostly did work but had to start it
from user settings autostart.