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
_______________________________________________
Pkg-utopia-maintainers mailing list
Pkg-utopia-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
