[Pkg-utopia-maintainers] Bug#923240: policykit-1: Please support alternative logind implementations

[Simon McVittie]

Control: tags -1 + moreinfo

On Mon, 25 Feb 2019 at 10:58:49 +0000, Mark Hindley wrote:
> For desktops to be installable on such systems, policykit-1 needs to depend on
> the newly approved virtual packages default-logind and logind. In the latest
> upload of src:systemd, libpam-systemd provides default-logind.

Sorry for the delay in getting back to you on this. Non-critical changes
to important components like policykit-1 did not seem like a good idea
during the buster release freeze.

Does polkit work correctly on systems that use elogind, without any
further source or binary changes? It is not enough that a logind-like
service is merely installed and monitoring sessions: to keep polkit's
core functionality working, it has to be able to query logind's state
via libsystemd.so.0 APIs.

For example, when polkitd calls sd_pid_get_session(), if the system is
using elogind, the API call needs to return whether pid is part of an
elogind session.

Please could you describe how this is meant to work on systems that use
elogind? Which packages are meant to be installed to make this work?

For comparison, here is how it works on systemd systems:

- libpam_systemd is invoked on login and logout
- libpam_systemd communicates with systemd-logind to update its knowledge
  of login sessions
- polkitd is linked to libsystemd.so.0, which is provided by libsystemd0
- libsystemd0 communicates with systemd-logind via D-Bus, or by reading
  files in /run/systemd that are considered private to the combination
  of systemd-logind and libsystemd0 (mainly /run/systemd/seats and
  /run/systemd/sessions, I think)

Which parts of that architecture get replaced when using elogind?

When a bug is reported in policykit-1 on a system that is using elogind,
does the reportbug-generated message template indicate that? Is there
someone among the elogind maintainers who can help with such bugs if
they appear to be integration issues between policykit-1 and elogind?

(If the reportbug-generated message template with your proposed patch
doesn't currently indicate systemd-logind vs. elogind, it should be
possible to fix that by putting appropriate runes in
debian/policykit-1.bug-control.)

> There is a separate issue about backend support for elogind. I will
> open a separate bug for that.

Does that separate bug exist, or has the question of backend support
become irrelevant due to changes in the design of how elogind fits into
Debian since you opened this bug?

On Fri, 09 Aug 2019 at 14:15:17 +0200, Svante Signell wrote:
> Please explain your decision on why desktops for other
> init systems are excluded (even in sid).

Please don't assume that the absence of action is a deliberate decision.
All of policykit-1's maintainers (both upstream and in Debian) mostly
work on other things and don't have a huge amount of time available for
policykit-1. This makes us reluctant to risk creating the possibility
of non-functional combinations of packages that will take more of our
time to debug.

    smcv