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

Armin K. krejzi at email.com
Sat May 10 04:15:16 PDT 2014


On 05/10/2014 04:37 AM, Bruce Dubbs wrote:
> I have spent the last several days trying to understand the internals of
> dbus, polkit, and consolekit in an attempt to integrate System V and
> systemd.
> 
> I have not been successful.  The linkages are not transparent at all.
> For example lxsession-logout tries to get permissions for poweroff or
> reboot in a very complex way.
> 
> It calls dbus to get permissions for systemd-logind.  While running
> System V, this fails and that is quite understandable.
> 
> It then tries consolekit.  I tried to trace it through dbus to
> console-kit-daemon and from there to polkit-1/polkitd.  I was not able
> to figure out how the decision to accept or deny a simple function like
> CanRestart is made.  The interfaces through dbus and really complex glib
> functions was beyond what I can understand without a *lot* more study.
> For example, from polkit:
> 
> g_dbus_proxy_call (authority->proxy,
>     "CheckAuthorization",
>     g_variant_new ("(@(sa{sv})s at a{ss}us)",
>         subject_value,
>         action_id,
>         details_value,
>         flags,
>         data->cancellation_id != NULL ? data->cancellation_id : ""),
>     G_DBUS_CALL_FLAGS_NONE,
>     G_MAXINT, /* no timeout */
>     cancellable,
>     (GAsyncReadyCallback) check_authorization_cb,
>     data);
> 
> I looked at the documentation and "(@(sa{sv})s at a{ss}us)" (glib) is still
> a mystery to me.  What is the proxy?  I still can't tell.
> 
> 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. 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.

If the older "group membership" method is used to grant an user access
to the video and/or audio card, hard drives, scanners and what not, that
would be possible from a remote location too. You also don't want remote
user to be able to reboot your system when logged from a distant place
if you have physical access to the system.

ConsoleKit, as the name might point out, is the stuff that checks and
grants permissions to users that log in and log out to the system based
on how and from where they did log in. That's done via PAM module.

The "at_console" DBus property (or whatever the right name is) is used
in several DBus rule files and such interfaces can only be accessed if
user is logged in from a "console" (in this case, older interpretation
of physical access to a machine). So from all these years I have been
working with desktops this is what I have managed to learn:

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.

When something needs a password, policykit comes into play. It's used to
handle authorization for certain tasks. Also, much like DBus, it has its
set of rules and when certain conditions are met, password won't be
asked, otherwise it will.

Password is asked when an user tries to ie, umount a drive that was
mounted by someone else or shut down the machine while there are other
users logged in. Same as using root access to do stuff, but in a dummy
proof way.

systemd-logind is the same, just replace ConsoleKit with it in systemd
based system and it does the same. Both are *session* managers and
manage user sessions on a single system.

As for why DBus tries to access systemd-logind instead of ConsoleKit on
sysvinit based distro, the answer might be that dbus-daemon has logind
support linked in and it will use it instead of CK.

> My question then is "In today's environment, where does all this fit
> in".  Are there many places where multiple desktop environments are
> needed on a single system?  I am certainly not aware of that.
> 
> I do have experience working on supercomputers where there are many
> users competing for run time.  The thing there is that there are no
> desktop environments.  You just ssh in and do what is needed from the
> command line.  In some cases there are web based interfaces, but
> certainly not desktops.
> 
> One advantage of systemd is to speed up the boot process by running
> multiple boot processes in parallel.  On LFS it is faster.  On my
> hardware systemd boots in 8 seconds and System V boots in 10 seconds.
> that's hardly a substantial reason for a massive complication of the
> boot process and many programs within the overall system.
> 
> I've said it before: it appears that systemd is a solution in search of
> a problem.  For 99% of users, especially LFS users, systemd provides no
> discernible benefits and a lot of problems.  You are either all in or
> not.  There does not seem to be a halfway.
> 
> Unless I get some feedback in the next couple of days with solid reasons
> that systemd, polkit, and consolekit are important, I am going to
> replace systemd with eudev in LFS and minimize recommendations for
> polkit and consolekit in BLFS.
> 
> I'm a little undecided whether dbus should remain in LFS or not.  It
> doesn't hurt much, but it also isn't much use in an non-xorg environment
> unless you are using systemd.  To use it in an xorg environment, it (at
> least dbus-launch) needs to be built after xorg-libs.
> 
> Many users come to LFS because they don't want the "bloat" of the
> commercial distros.  I am now willing to return to those roots.
> 
> Feedback is welcome.
> 
>   -- Bruce


-- 
Note: My last name is not Krejzi.


More information about the lfs-dev mailing list