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

Aleksandar Kuktin akuktin at gmail.com
Sat May 10 08:29:32 PDT 2014


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

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

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.

-- 
Svi moji e-mailovi su kriptografski potpisani. Proverite ih.
All of my e-mails are cryptographically signed. Verify them.
--
You don't need an AI for a robot uprising.
Humans will do just fine.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20140510/5afd4eb8/attachment.sig>


More information about the lfs-dev mailing list