On Sat, Oct 05, 2019 at 08:39:42PM +0100, Mark Hindley wrote:
> Svante,
>
> On Sat, Oct 05, 2019 at 08:45:55PM +0200, Svante Signell wrote:
> > What does libpam-elogind provide, and which version are you talking about?
> > elogind-234.4-2 is in ascii, but beowulf has elogind-241.3-1, i.e. the same
> > version as Debian.
>
> Beowulf has src:elogind 241.3-1. Its libpam-elogind package also Provides
> libpam-systemd so that packages which come directly from Debian with a
> libpam-systemd dependency can be used in Devuan without forking or any
> recompilation.
>
> The debian version is actually different (241.3-1+debian1) as the packaging for
> debian has some differences from devuan's.
>
> > I think we should fork that package. As for now it is built with libsystemd-dev
> > not libelogind-dev!
>
> That isn't necessary and doesn't matter. AFAIK it works just using the debian
> packages. We only need to fork it if we want a version without logind support.
>
> udisks doesn't actually use libpam-systemd/libpam-elogind itself, it just
> requires the user session to be registered with logind so that it can associate
> pids with the session. So it doesn't care which implementation of logind has
> done that.
> [...]

My personal feeling about this: udisks should not depend on libpam* at
all. My reasoning for this: In no case udisks should care about installed
pam modules. udisks uses policykit but not pam to determine if a mount is allowed or
not. It is up to the policykit package to require proper pam-modules to be
installed since policykit needs to be functional by itself even without
udisks installed.

Besides that, I found udisk2 has built in dependency on path
"/run/systemd/seats". If that path doesn't exists, the only used
liblogind* function "sd_uid_is_on_seat" will never be called. Does
elogind expose this path? (*)

The remaining call to logind api go through explicit dbus call, without
using the abi sd_* functions. This call will have no effect on
elogind systems, since elogin can not "Inhibit" system shutdown... (**)

notes:

[*] The only thing this function call is used for is to prevent the same
user but coming from a different session to perform an action on a block
device already used in another session of the user. E.g. If someone is logged
through GUI in the system and has mounted an USB-Stick, it is not possible
to login on text console (tty) with same user and unmount the stick.
For me this sounds like an ill formed use-case.

[**] So, my personal oppinion: The dependency on liblogind/elogind can be
completely removed from udisks: Except (*) above there is no binary
dependency. Besides there is also no functional dependency on elogind,
since elogind can not inhibit anything.

Andreas

--
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51