Starting the kdbus discussions

[Lennart Poettering]

On Fri, 10.01.14 13:41, Yang Chengwei (chengwei.yang at intel.com) wrote:

> Meanwhile, as I understand, the *temporary* solution is connect to bus
> proxy, this just cancel out some of the kdbus performance gain. And make
> the whole picture more complicated, so one day all the application
> developer must sign up to the pain to adopt their own security policy to
> work with kdbus. Otherwise, bus proxy will become another dbus-daemon
> which is targeted to be replaced by kdbus I think.

BTW, to give a hint how big the "pain" will be: in libsystemd-bus the
policy for the simple cases is simply built into the method definitions.

Here's an example how this looks for the Session object logind provides:

http://cgit.freedesktop.org/systemd/systemd/tree/src/login/logind-session-dbus.c#n458

By default, methods are not accessible to unpriviliged clients, however,
a special flag SD_BUS_VTABLE_UNPRIVILIGED will open it up. Also,
optionally, if the flag is not specified one may use
SD_BUS_VTABLE_CAPABILITY() as a meta-flag to change the client side
capability the library will look for when making the access decision. If
this is not specified CAP_SYS_ADMIN is checked for.

I'd would suggestt that other libraries for dbus would do this similar:
simply decorate the functions with trivial access flags (though it might
make sense to simply hardcode this to one specific cap, if they dont
want to expose such low-level bits).

Note that SD_BUS_VTABLE_UNPRIVILIGED opens up the method call to
clients, however, in most cases the logind code will then still do a
PolicyKit check to verify more things before executing any operation.

Specifiyng SD_BUS_VTABLE_UNPRIVILIGED on interfaces exposed on the
session bus has no effect.

Lennart

-- 
Lennart Poettering, Red Hat