Adam Borowski wrote on 19.01.2018 15:56:
On Fri, Jan 19, 2018 at 02:17:28PM +0100, Irrwahn wrote:
I think that has to be done anyway, because currently one cannot
have policykit without having consolekit installed with it, due to
the "Depends". The package should have something akin to:
Depends: libpam-elogind | consolekit
Anyone up for the task?
You would have to change policykit to allow runtime detection of logind vs
consolekit. Currently it can be compiled only one way or the other.
Oh, crud! Nothings ever easy. Having two versions of policykit
probably would be an even worse idea, wouldn't it?
The dbus API is incompatible. Both can coexist, but it's a bad idea to have
consolekit be unaware of sessions handled by logind -- thus, if you want to
keep consolekit alive, it'd better to implement logind API, as that's what
the desktop environments ecosystem moved to.
I somehow doubt there's a lot of capable people willing to
do it. Of course, I'd be happily proven wrong on that account.
Devuan doesn't (currently?) support non-Linux kernels, but Debian/kfreebsd
and Debian/hurd guys would thank you for this.
Hm, that increases the chances again, I guess.
On the other hand, I have doubts whether logind or consolekit are the best
approaches. The more I look at them, the more I boggle about the
pointlessness of the whole concept of "sessions": with systemd, you can't
have more than one GUI session; when a GUI session is on, ssh-ing in lets
you access all resources that are supposed to be restricted to that GUI
session; switching to another VT stops music from playing (because
security). Thus, if you drop things we don't want, it all boils down to
"does this user have a locally logged in session?". Type "who" and here's
your answer. It would be possible to have a thin stub that answers dbus
requests with standard POSIX backends, or similar non-NIH tools like
pm-suspend.
[Rant]
Honestly, I'm already close to the point to kick all that session bullshit
to the curb, and go back to startx or the like to bring up a graphical
environment, and sudo-mount my thumbdrives, or whatever. And before anyone
cries "but, but, but security": there are much, much more serious security
holes to plug, besides me running X as root on my @/)%$$ desktop!)
[/Rant]
Such a stub would lose that "fast user switching" feature, but come on -- we
live in a many computers per person world, rather than many persons per
computer as it was the case in the past. Thus, my idea would have the
following assumptions:
* someone with physical access can always shutdown/reboot the machine: if
the software disagrees, there's a big button and a small one close to it,
if even that fails, there's a power cord (or a laptop battery). Kiosks
are about the only cases to the contrary, and they already restrict you
from issuing a "shutdown" command anyway.
* multiple remote users are an important use case, both for command-line and
GUI (vnc/...) logins
* conversely, multiple local users don't matter anymore: everyone has
multiple screen-attached computers. Note the name: _personal_ computer.
When I say this, someone always responds with "but sub-saharan
classrooms". Nope: ages ago we had such a situation in our world, and
I don't remember a single case when kids had separate accounts where
they'd lock a session before passing the keyboard to their neighbour.
Thus, I knowingly dismiss a valid use case as irrelevant, to buy us KISS.
It's not so different from systemd: it disallows you to log in via vnc if
you have a local session, which is an use case I did need in the past.
I wholeheartedly agree. I never were able to find a single person that
used, lest relied upon, that multi-seat/multi-session pseudo-feature.
We've come a long way since 1984.
