[lfs-dev] dbus, systemd, polkit, and consolekit
bruce.dubbs at gmail.com
Sat May 10 08:52:11 PDT 2014
Aleksandar Kuktin wrote:
>> On Sat, 10 May 2014 13:15:16 +0200
>> "Armin K." <krejzi at email.com> wrote:
>> On 05/10/2014 04:37 AM, Bruce Dubbs wrote:
>>> I tried to step back and see just what is all this dbus, systemd,
>>> polkit, and consolekit stuff all about. My conclusion is that it
>>> is to manage multiple simultaneous desktops on a single system.
>> Almost true. It's rather there to manage multiple simultaneous *users*
>> on a single system, aka "multiseat" but its modern interpretation, not
>> the old stuff from 70s.
> Okay. Now we're talking. :) It there somewhere a place where we can
> read the new ruminations about the new interpretations and develop our
> beliefs about them?
>> In that way, several users can be logged in, while the only one of
>> them will get permissions to access the input and output devices that
>> are tied to the workstation he's currently working at. Others, while
>> they may be logged in via SSH or who knows what other way won't be
>> able to use such devices because they are not using them physically.
> It should be noted that there are few situations where this is actually
> usable in the real world. What I am picturing right now is technical
> support logging into a workstation to "do something" while the
> workstation user (or the System) doesn't trust technical support to not
> mess things up. But in that case, why the **** have you hired them? Or
> took on a contractor whose people you do not trust?
I do have some experience with multiple xorg instantiations on one
central system. We used them via vnc where multiple users could log
into the same virtual workstation for development purposes while talking
on the phone. It was convenient and effective, but I see this as a rare
situation. We were also able to do it without systemd.
>> When non root user tries to access interfaces that were not meant for
>> every normal user to use under certain conditions (explanation above,
>> access to hardware) using DBus, DBus will first ask ConsoleKit if the
>> user is logged from local machine, and if so, the permission will be
>> granted for some things to do without a password, while other things
>> would need a password.
> I can't remember right now what is the "normal" method of accessing
> stuff on Linux (something related to ioctl(), right?), but what exactly
> is wrong with that? (Apart from the fact that ioctl() is a crawling
> horror, ofcourse.) Another question is what happens if the user
> attempts to access hardware by a method that is not DBus dependent
> (like ioctl(), for example :) )?
> Add to that that DBus is a userland process that can only be
> communicated to through the kernel, and that DBus also communicates with
> other userland processes, and you have exploded the amount of work that
> needs to be done.
> For every single PolicyKit check, the message needs to cross the
> userland-kernelland boundary four times in one direction, followed by
> another four passes in the other direction, plus message forming,
> parsing, decoding and other.
Sometimes more. User to dbus to consolekit to polkit or systemd-logind
or upowerd and back again. I will say that the number of messages would
be pretty small and not really affect performance.
I understand that there is also an effort for kdbus to be integrated
into the kernel. I'm not sure Linus will approve though. When I looked
at dbus, it was 100K lines of C code. That's huge for what is basically
a message passing system.
More information about the lfs-dev