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. > > 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) True dat. That's one, if not /the/, crucial point. I'd volunteer to support such an endeavor in whatever way I can, however writing stuff like that from scratch is currently beyond my capabilities, and would probably drive what's left of my sanity right over the edge (I've touched dbus before, will never touch that POC again!), so unfortunately I too have to pass on taking a lead role in that, sorry. > > Meow! Eek! Urban -- Sapere aude! _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
