On Fri, Jan 19, 2018 at 02:17:28PM +0100, Irrwahn wrote: > > It seems to me that these issues are caused by policykit, in devuan it > > doesn't support logind (obviously) so it's unable to authenticate > > user's requests. > > Yes, that appears to be the most likely explanation. > > > Maybe we need to rebuild it with support for elogind. > > 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. 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. Devuan doesn't (currently?) support non-Linux kernels, but Debian/kfreebsd and Debian/hurd guys would thank you for this. 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. 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. But, it's good to have elogind available, even if just for a transition. For starters, such an unix-logind doesn't exist yet. Vapourware that I don't volunteer to write is quite a weak argument... (Compare the complete code of loginkit: https://github.com/dimkr/LoginKit/blob/jessie/loginkitd/loginkitd.c) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the ⠈⠳⣄⠀⠀⠀⠀ sky. Your cat demands food. The priority should be obvious... _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
