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

[Mark Hindley]

Control: tags -1 - moreinfo

Simon,

Many thanks for this.

On Fri, Aug 09, 2019 at 02:35:13PM +0100, Simon McVittie wrote:
> 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.

Yes, I understand that. It also seems to me that now, early in the bullseye
cycle, is a good time for such changes.

> 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.

Yes, it works in my testing. I have had a number of other reports of success too
with a variety of desktops (xfce, mate, budgie, cinnamon and even gnome).

Since #923244 was resolved in version 241.1-1+debian1, libelogind0 is ABI
compatible with libsystemd0 and exposes the same symbols for runtime linking,
although providing a subset of functionality. This is explained fully in the
libelogind0 package description: sd-login(3), sd-bus(3) and sd-id128(3) APIs are
implemented in full with most other functions returning -ENOSYS. libelogind0
also provides a libsystemd.so symlink so that applications compiled against
systemd work with libelogind0 at runtime.
 
> 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?

In exactly the same way. libpam-elogind is invoked at login/logout and updates
elogind's record of sessions. polkitd calls functions in libelogind.so via its
libsystemd.so symlink to retrieve information on users, sessions and their
related processes.

> 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.)

I will be very happy to work to resolve issues related to elogind and its
integration with other packages. You are correct that a reportbug template
including that information would be useful.

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

Yes that was #923244 which has now been solved by runtime ABI compatibility
rather than the original suggestion of alternative backend packages.

> 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.

I understand. To help prevent that libelogind0 conflicts with systemd itself so
that the non-functional situation of systemd with libelogind0 is not possible.

Thanks and best wishes.

Mark