[systemd-devel] systemctl as non-root

[Lennart Poettering]

On Fri, 29.05.15 13:56, Mantas Mikulėnas (grawity at gmail.com) wrote:

> > systemd will always use D-Bus (the protocol) for IPC, that's not
> > optional, and you cannot turn it off neither during build-time nor
> > during runtime. systemd does not use libdbus to implement this
> > however, but instead it uses its own D-Bus client implementation,
> > dubbed "sd-bus", which is going to be a public API with the next
> > systemd release.
> >
> > Optional however is whether dbus-daemon (the daemon) is used as for
> > IPC, or if all dbus IPC takes place only between systemd and its
> > clients via direct AF_UNIX connections, without the central bus
> > concept. We support this mode mostly to cover for the early-boot phase
> > where dbus-daemon is not running yet, and hence cannot be used for
> > communication. Running in this mode even during normal operation is
> > supported, but not recommended (which is why the README says: "dbus is
> > strictly speaking optional, but recommended").
> >
> > The direct AF_UNIX communication is available exclusively for
> > privileged clients. Normally it's the duty of dbus-daemon to enforce
> > more complex policy on dbus1 systems. If you take dbus-daemon out of
> > the equation however, then this policy component will be missing, and
> > hence systemd refuses to talk to any unprivileged clients.
> >
> 
> Hmm, in a kdbus world, systemd (the service) itself would be responsible
> for policy checks anyway, wouldn't it? I mean, it already does the
> polkit/selinux checks even on dbus1 systems.

Correct. However, it does so in cooperation with sd-bus and
kdbus. kdbus provides per-method call credentials, which allows us to
properly authenticate the individual method call. kdbus also does
per-service access control, and sd-bus provides support for defining
access control for methods in a static way. All together in systemd on
kdbus there are four layers of access checks applied:

      1. kdbus own per-service policy
      2. sd-bus' static per-method capability based checks, as
         declared in the object vtables
      3. dynamic access control on objects, enforced by systemd itself
         based on capabalities, uids, and policykit
      4. selinux checks based on object and client labels

Only if all four layers allow access, access is actually granted.

In the long run I hope to add some more helpers to make it easier to
implement the schemes of #3 in external services. Currently we have
some internal glue that makes invocation of policykit easy, but we
should probably provide a public API for that right in sd-bus, too.

Lennart

-- 
Lennart Poettering, Red Hat