[systemd-devel] Polkit and systemd D-Bus API

Stef Walter stef at thewalter.net
Tue Jul 15 06:38:41 PDT 2014


On 15.07.2014 15:15, Lennart Poettering wrote:
> On Tue, 15.07.14 13:35, Stef Walter (stef at thewalter.net) wrote:
> 
>> Cockpit, OpenLMI, and others want to use the systemd D-Bus API to manage
>> system services/sockets etc. In addition we use polkit to authorize
>> users and allow people to escalate privileges as needed.
>>
>> It seems that the D-Bus API of systemd doesn't support polkit:
>>
>> http://www.freedesktop.org/wiki/Software/systemd/dbus/
>>
>> So currently only root users can call this D-Bus API.
>>
>> Is the concept here that we write our own wrapper daemon (something like
>> systemd-polkit-verifyd) that listens on a different bus name and
>> authorizes with polkit before forwarding messages to systemd?
> 
> Previously our hook up with PK was awful, and could cause deadlocks when
> done from PID 1, which would then be both the process managing polkitd
> and its client -- which is why I never did polkit support for PID 1
> calls, but only for the other daemons. But this has been fixed since
> then, the polkit queries are now fully asynchronous, and we should
> probably open this up via polkit.
> 
> Which bus calls precisely are you interested in?

Since Cockpit has a pretty comprehensive UI for systemd units, it'd be
easier to list the DBus calls we're not interested in. But here goes,
off the top of my head:

 * All of the *Unit() calls and Unit object methods/properties
 * All of the *Job() calls
 * Subscribe()/Unsubscribe()
 * SetUnitProperties()
 * SetDefaultTarget()
 * StartTransientUnit()
 * ResetFailed()
 * readable properties
 * signals...

Not sure about:

 * Halt(), PowerOff(), Reboot()
 * *UnitFiles()

Not interested:

 * Reexecute(), Kexec()
 * SwitchRoot()
 * *Snapshot()

Also, usually most properties are be readable by unpriveleged users. Are
there any in systemd where this wouldn't be the case?

Stef

-- 

stef at thewalter.net
http://stef.thewalter.net


More information about the systemd-devel mailing list