Bug#923240: policykit-1: Please support alternative logind implementations

[Mark Hindley]

Package: policykit-1
Version: 0.105-25
Severity: important
Tags: patch

Dear Maintainers,

elogind is an alternative Dbus login1 implementation for systems not running
systemd as pid 1. It is in buster.

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.

The necessary patch is:

commit 84e3b4c4ebeddd7e05aade51ac77f63ab99022eb
Author: Mark Hindley <***@hindley.org.uk>
Date: Mon Feb 25 10:47:36 2019 +0000

Depend on new vitual packages default-logind and logind.

diff --git a/debian/control b/debian/control
index ac9825d..83386e9 100644
--- a/debian/control
+++ b/debian/control
@@ -33,7 +33,7 @@ Architecture: any
Depends:
consolekit [!linux-any],
dbus,
- libpam-systemd [linux-any],
+ default-logind [linux-any] | logind [linux-any],
${misc:Depends},
${shlibs:Depends},
Multi-Arch: foreign

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

Thanks

Mark

[Mark Hindley]

Control: tags -1 - moreinfo

Simon,

Many thanks for this.

Control: tags -1 + moreinfo

Post by Mark Hindley
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?
- 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.

Post by Mark Hindley
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.

Post by Mark Hindley
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

[Mark Hindley]

Post by Mark Hindley

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.

I think debian/policykit-1.bug-control with the contents

package-status: libsystemd0 libelogind0

is sufficient.

Mark

[Simon McVittie]

Control: tags -1 + pending

Post by Mark Hindley

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.

Yes, this is a much better time for that sort of thing (you'll notice that
the upload I'm preparing has some other potentially-disruptive changes).

Post by Mark Hindley
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.

I hope sd-daemon(3) is also implemented? Before it was absorbed into
libsystemd, that used to be a "copylib" intended to be pasted into portable
software like dbus-daemon - so hopefully it's still usable as a standalone
implementation of things like the LISTEN_FDS protocol.

Post by Mark Hindley
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.

Thanks, please subscribe to policykit-1 bugs so that you can keep an eye
on this.

Unfortunately reportbug doesn't currently tell us who is implementing
default-logind, logind or libsystemd0 - I think this is because
of the versioned Provides, and I've reported that as #934472 in
reportbug. I've worked around that by adding reportbug metadata to get
elogind, libpam-elogind, libpam-systemd and libsystemd versions to be
included in bug reports. Hopefully there will not be a third parallel
implementation any time soon.

If elogind support results in a disproportionate number of bug reports,
we might have to either revert your change, or add a presubj file
asking elogind users to report bugs that cannot be reproduced with
systemd-logind against elogind instead of policykit-1 - but hopefully
that won't be necessary.

smcv

[Mark Hindley]

Post by Simon McVittie
I hope sd-daemon(3) is also implemented? Before it was absorbed into
libsystemd, that used to be a "copylib" intended to be pasted into portable
software like dbus-daemon - so hopefully it's still usable as a standalone
implementation of things like the LISTEN_FDS protocol.

Yes. I will add that to the description. The one exception is sd_is_mq() as
upstream has excluded POSIX message queues from the implementation.

Mark

[Simon McVittie]

Post by Mark Hindley

Post by Simon McVittie
I hope sd-daemon(3) is also implemented? Before it was absorbed into
libsystemd, that used to be a "copylib" intended to be pasted into portable
software like dbus-daemon - so hopefully it's still usable as a standalone
implementation of things like the LISTEN_FDS protocol.

Yes. I will add that to the description. The one exception is sd_is_mq() as
upstream has excluded POSIX message queues from the implementation.

I think that's probably fine - I suspect the original implementation in
systemd only included sd_is_mq() out of a sense of completeness, and it
used to cause build problems in dbus when we were using the original
"copylib" version, because it was the only thing pulling in librt.

smcv

[Chris Zubrzycki]

Please get this working somehow. I do not wish to finally have to switch to devuan, but if I can not use virt-manager anymore (which requires policykit-1) I will have to do it.

Thanks!

[Simon McVittie]

Post by Chris Zubrzycki
Please get this working somehow. I do not wish to finally have to
switch to devuan, but if I can not use virt-manager anymore (which
requires policykit-1) I will have to do it.

"Me too" messages are not particularly useful. If a maintainer already
wants to support non-systemd init systems, the factor preventing them
from doing so is most likely to be lack of time, missing information,
or not enough help; stating that you want a solution does not provide
any of these.

If a maintainer already does not want to support non-systemd init systems,
threatening to switch to Devuan is likely to have the opposite of the
effect you intend: you're effectively telling such maintainers "if you
don't do this, we will stop causing extra maintenance work for you".
I doubt that is the effect you were looking for.

smcv

[Mark Hindley]

Post by Mark Hindley
Yes. I will add that to the description. The one exception is sd_is_mq() as
upstream has excluded POSIX message queues from the implementation.

I think that's probably fine - I suspect the original implementation in
systemd only included sd_is_mq() out of a sense of completeness, and it
used to cause build problems in dbus when we were using the original
"copylib" version, because it was the only thing pulling in librt.

AFAIK that is also the reason elogind upstream have not implemented it -- to
avoid the librt dependency.

Mark