Hello all, sorry for beeing mute for so long, but i was busy with other things, and still have not much time at the moment
On Fri, Jan 19, 2018 at 11:48:43AM +0100, Irrwahn wrote: > Andreas Messer wrote on 19.01.2018 07:16: > > That seems strange. loginctl is a elogind command and when elogind does not > > know about the session loginctl should reject or ask for auth. I'll dig into > > this a little bit more. Probably time to setup a vm. > > So, I did a little more testing: > [...] Thank you very much for the elaborate testing! Taken all the test results into account so far, I conclude we should mark elogind "Conflicts: consolekit". When both are available, one seems not be working properly. Furthermore elogind should get some default configuration which make it to not cause unexpected side effects: - disable killing of porcesses when session ends - ... On Fri, Jan 19, 2018 at 03:56:22PM +0100, Adam Borowski wrote: > [...] > 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 fully agree with that. > 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 > [...] Well, I use :-). On Fri, Jan 19, 2018 at 05:34:23PM +0000, KatolaZ wrote: > On Fri, Jan 19, 2018 at 06:03:59PM +0100, Didier Kryn wrote: > > But wether that session is local or not is, in my opinion, and as I > > already said, futile; and it seems to be mostly used as a justification to > > develop a tangle of daemons and middleware to bypass the traditional unix > > security framework. > > This is where I get totally lost with sessions: why on Earth should I > be able to mount an external device on a remote host to which I login > via SSH? Or unable to do that, if I am a regular user of that machine? > What is the use case for this madness? Does it really solve a problem, > or is just the usual non-working and useless solution to a problem > that doesn't even exist? For me, the mainreason to have this is. Just imagine the case of a machine having a desktop, but also regulary used by other remote users. We had this scenario at university - all desktops where used to run simulation jobs remotely by all users while the secretary was typing in letters. In that case a remote use should not be able to mount USB stick plugged in by the secretary. There also scenarios, where such desktops are not assigned to a particular user but used by different users. (Students Computer pool) The you really want allow mounting only to the guy logged in and sitting in front of the screen. I you dont want to use it on your system, just dont install it. [...] So for me, there is a need for such a function on a desktop system. I could agree with the problem that logind is doing much more than it should. I really dislike that it: - kills process depending on its decision - manipulates control groups - we have already daemons for this - reboots/shutdowns/supsends the system if it like to do so I'm not fully sure, but as far as I understand consolekit does not do such things, so from my viewpoint consolekit is the one to prefer. It is more unix spirit. But we need a solution to allow for different DEs to be used in devuan and for now, many DEs require logind. So my oppinion is, that, at least for transition or migration purposes we need to provide two paths in devuan, the user needs to choose one of them - consolekit(2) + policykit - elogind + policykit-logind Generally i would like to see get rid of all systemd originating software monoliths. So what i could imagine: - Create a logind replacement which redirects all dbus queries to consolekit and let consolekit doe the session management. dbus queries for which no consolekit stuff exists (e.g. shutdown/reboot...) could be simply fan out into an external command, e.g. shell script. Its up to the administrator/maintainer whats happens then. Using this we can have consolekit and logind api at the same time while not struggling with two session management systems. - Create a minimal logind replacement which uses unix commands as thought of by Adam. This can be used by people who want install DEs requiring logind but dont want ck or logind to be installed If this is possible, every one can choose what he like and what fits her/his needs. That is the spirit of linux. Cheers, Andreas
signature.asc
Description: PGP signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
