[systemd-devel] systemctl as non-root

[Lennart Poettering]

On Thu, 28.05.15 17:21, Aaron_Wright at selinc.com (Aaron_Wright at selinc.com) wrote:

> Brandon Philips <brandon at ifup.co> wrote on 05/28/2015 05:10:33 PM:
> > Access to the system dbus is controlled by dbus policies. You will 
> > need to write a policy for giving this user access to the systemd1 
> object.
> >
> 
> I compiled systemd without dbus support (--disable-dbus), and there is no 
> dbus daemon or dbus lib on the system. Is that a requirement to get the 
> functionality I want? I didn't see much need for dbus as the system works 
> quite well without it. Well, except for this of course.

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.

Long story short: you cannot avoid dbus IPC really. Please use
dbus-daemon, it's recommended. If you choose not to anyway, then you
will not have access to systemd's APIs from unprivileged APIs.

Lennart

-- 
Lennart Poettering, Red Hat