Starting the kdbus discussions

Lennart Poettering mzqohf at 0pointer.de
Fri Jan 3 15:06:52 PST 2014


On Thu, 02.01.14 14:40, Colin Walters (walters at verbum.org) wrote:

> 
> On Thu, 2014-01-02 at 14:24 -0500, Colin Walters wrote:
> > On Mon, 2013-12-30 at 04:50 +0100, Lennart Poettering wrote:
> > 
> > > Well, it's not that different from today. On Fedora at least we ship a
> > > systemd service file each for all bus-activated system service these days,
> 
> [snip some text]
> 
> Sorry, I see you replied to this later.  
> 
> > Now, there's one big difference when connecting directly to kdbus
> > vs. indirectly via the proxy: the old XML policy language is not used
> > on
> > kdbus directly, the kernel enforces more Unix-like ACLs on service
> > names, and will not enforce anything on members/interfaces and so on,
> > the way dbus1 allowed that in the XML policy. When connecting to the
> > kdbus system bus directly you need to be aware of that, and do your
> > own
> > access control (which is a lot easier to do though than in dbus1,
> > since
> > messages carry creds and caps from the sender anyway).
> 
> Right, that is a serious concern.  Enough to make me wonder if GLib
> should have G_BUS_TYPE_KSYSTEM for example.
> 
> But...eww.  It'd be unfortunate to penalize all GDBus users just for the
> sake of services which are still installing policy files though =/
> 
> Hmm.  Perhaps an alternative is that if *any* files are installed
> in /etc/dbus-1/system.d that perform access control, then kdbus is
> disabled?  Ugly still.
> 
> Another option is to punt to the system builder; GLib would have a
> compile-time option --enable-kdbus, and any system builder using
> this would take responsibility for ensuring that no GDBus-using clients
> are installing DBus XML policy.
> 
> Any other ideas?

Here's another idea: gdbus could be updated to enforce the XML policy on
the client side. It's not that hard (glib has an xml parser already
after all that is good enough for this), it's what the proxy does now
too (though I actually haven't pushed that commit yet). In dbus-daemon
one couldn't replicate the full policy on the client side, since you
lack information about well-known names of senders of incoming
messages. However on kdbus you get all that, so you can actually make
the exact same decisions client-side as dbus-daemon currently makes
server-side.

Of course, this would still require a way how gdbus is told about the
specific xml file to enforce, or whether there isn't any in the first
place.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the dbus mailing list