Disabling new D-Bus protocol features by default

Marcel Holtmann marcel at holtmann.org
Tue Nov 9 00:07:43 PST 2010


Hi Thiago,

> > Also you don't wanna put more logic and safety inside the dbus-daemon
> > since that is the wrong place. I would actually consider taking more and
> > more checks out of the daemon for performance reasons and let the
> > applications/bindings deal with it. Relying on only valid data from
> > dbus-daemon is just wrong. That is a recipe for disaster.
> 
> Maybe so, but that's not what we've done. Right now, we trust the daemon and 
> it does have logic to not send the new types. And on the client side, the 
> behaviour on seeing new things is to disconnect. Before we talk about removing 
> the daemon safeties, we need to fix the clients.
> 
> I'm simply moving the control of the negotiation logic to the public.

so how does a client sees the new types if it has to negotiate the
support in the first place. I think the behavior of the client is
actually correct. It gets unexpected data and decides to just
disconnect.

What are you trying to fix here?

> > > This is a behaviour change in D-Bus 1.4, but I believe it's better to
> > > modify the few apps that are changing to support FD passing while we
> > > have time than the majority of the apps and the existing, released
> > > bindings that don't support the new feature.
> > 
> > This is too late now. Fedora 14 and the latest Ubuntu are shipping D-Bus
> > 1.4 and you would break API for applications already using FD passing
> > support.
> 
> Yes. For me, it's a security feature, so I think it's worth it. There mustn't 
> be more than a couple applications that use this feature right now.
> 
> > The right approach is to get the bindings fixed. And also to fix the
> > broken application. As stated above they are broken and vulnerable
> > anyway. I say clearly that the issue needs to be fixed at the root cause
> > and not worked around at some other place.
> 
> They are not broken because their security did work before. WE broke it in 
> upgrading D-Bus, so it's our fault and we should be the ones to fix it.
> 
> You're asking that we fix all applications and all bindings that made the 
> assumption that they knew all types possible. You're also asking that no one 
> use an old, bundled version of libdbus-1.

If a binding made the assumption it knew all data types, then that
binding has an issue already right now. In the end D-Bus is a wire
protocol and you have to treat it like that and handle unspecified data
types.

> If we don't apply this fix, then I think we must *immediately* make libdbus-1 
> stop disconnecting when it receives new types from the bus. We can't have 
> both.

How can libdbus-1 receive that unknown data type in the first place if
it has not negotiated the support for it? Am I missing something obvious
right now? Who is actually disconnecting who?

Regards

Marcel




More information about the dbus mailing list