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