On 15.07.2014 15:15, Lennart Poettering wrote: > On Tue, 15.07.14 13:35, Stef Walter ([email protected]) 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 -- [email protected] http://stef.thewalter.net _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
