Disabling new D-Bus protocol features by default

[Lennart Poettering]

On Mon, 08.11.10 18:20, Thiago Macieira (thiago at kde.org) wrote:

> I'd like to disable the Unix FD passing by default in libdbus-1.
> 
> The reason for this is that when running against old application and binding 
> code, receiving a message containing an FD causes unpredictable results. 
> Bindings are often written to assume they can understand any type thrown at 
> them, so they might throw a fit if they see a type they don't know.
> 
> This could be used as an attack vector from remote applications, including on 
> the system bus.
> 
> Applications and bindings that want to use Unix FD passing (or, in the future, 
> Maybe types and other things) will have to enable the feature by themselves, 
> by calling dbus_connection_open_with_flags or dbus_bus_get_with_flags (or their 
> private versions). The rationale is that applications didn't support FD 
> passing before, in D-Bus 1.2, so they are being modified right now to support 
> the feature anyway.
> 
> I thought we had agreed on this during the 1.3 development cycle, but 
> apparently it was forgotten. I've realised now that the patch was submitted 
> only for the Maybe types, see 
> https://bugs.freedesktop.org/show_bug.cgi?id=27857
> 
> Therefore, I'd like to apply this patch (or equivalent that works):
> 	https://bugs.freedesktop.org/attachment.cgi?id=36155
> 
> 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.

I don't think this is a good idea. This will break due to the fact that
the D-Bus client libs by default share a single connection among all
in-process users. If one in-process user needs fd passing and the other
is too fragile to deal with it, then things will necessarily go boom.

Supporting this per-connection will not work. If at all you need to make
this a per-filter flag. But I personally I believe that applications
which cannot deal with the data they receive should be fixed. It is
always a problem if apps choke if somebody sends them a different data
type then they expect. And whether that unexpected data type a classic
type, or a new one, doesn't really matter here. 

People *must* validate the data they receive. While D-Bus already does a
lot of work (too much I believe) for them, ultimately matching up the
function signatures to the messages received is a job for the app
itself.

(Besides that I detest flag-style fields in APIs. It's bad style. Just
add proper boolean flags.)

Can you point us to actual problem reports for this?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.