[lfs-dev] dbus, systemd, polkit, and consolekit

Armin K. krejzi at email.com
Sat May 10 08:55:37 PDT 2014


On 05/10/2014 05:29 PM, 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?
> 

I remember Bruce mentioned a multi seat setup that had several physical
consoles (each with monitor and keyboard or other input device)
connected to one ugh, machine, and all could use that machine at the
same time. One of  "modern" multi seat implementations is what I tried
(but it seems I failed) to explain in my reply. UNIX and UNIX Like OSes
are multi user systems by design. While setups mentioned at the
beginning of this message are not common nowadays (not that I've seen
any in my life), network and serial console access to the machine are
not so uncommon. You can have physical access (keyboard, mouse and
monitor connected to the machine), network access, be it VNC or SSH or
what not and other ways of having access I'm not familiar with. That's
what "modern" multi seat interpretation I was talking about (at least
that's how I managed to interpret it).

>> 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?
> 

Imagine a corporate network with thousands of users accessing some sort
of server with gui from a remote location. You don't want them to be
able to "see" what's for example, GPU rendering, what CD in the cd drive
contains, to "hear" what's playing through sound card, etc. But when
some of  these users physically interracts with the machine, you want it
to be able to see what's on the screen, to be able to play sound, mount
usb and/or cd drives, etc.

>> 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 :) )?
> 

See above. I certainly wouldn't want someone (ie, a family member that
also has physical access to the computer) that's logged in from a remote
location to see what am I currently watching or listening to.

As for second question, hardware is not accessed by DBus. Programs
merely ask DBus if the user is able to access certain device and if so,
session manager will grant access to the device node using ACL's. Disk
and Power management are done by separate daemons running as root,
udisksd and upowerd most commonly.

> 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.
> 
> Linux is an HPC system. HPC stands for High Performance Computing and
> that is the number *ONE* reasong anyone uses Linux. It's fast. In
> Linuses own words (parafrasing): "It's so fast that it will change the
> way you think about computers." Making the system slow will destroy the
> first and most important strong point of Linux.
> 

I am not preformance expert, but if you are using stuff that relies on
things mentioned above, the preformance impact this delivers over the
modern desktop environments is rather small.


-- 
Note: My last name is not Krejzi.


More information about the lfs-dev mailing list