Unix FD Passing

[Havoc Pennington]

Hi,

On Wed, May 20, 2009 at 6:21 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> If a binding doesn't do unix fd it should never be tempted to generate
> a message with unix fds. Hence it doesn't matter if the connection it
> is using has negotiated it or not.
>
> If a binding doesn't do unix fd it should never be tempted to expose
> an interface that needs unix fds and hence never expect a message with
> unix fds. And hence again, it doesn't mater if the connection it is
> using has negotiated it or not.

Multiple bindings can use a connection; and it's possible to subscribe
to things like "all signals from app foo" and get whatever that app
sends out. So it's very easy to get an fd-containing message in
existing code that never knew anything about fd messages.

> The exception are the tools that try to genericly handle all kinds of
> messages. i.e. d-feet, dbus-monitor and such. And they should simply
> make sure to fail cleanly on messages they cannot produce or cannot
> parse.

libdbus does not really support such clean failure, because the API
did not anticipate it. The guarantee about is_fixed() implying that
get_fixed_array() would work is one example. But just in general, I
think the ABI guaranteed a known set of types.

> I really don't think that nego between libdbus and the client/binding
> would be a good choice.

We don't need to negotiate in-process I don't think, just have a
feature level that controls which features we negotiate when we auth.
Post-auth this should not affect the libdbus code in any way (setting
feature level should purely control which features we negotiate during
auth).

> I think the best option is to document that clients/bindings should
> *never* try to genericly handle types they don't fully
> understand. Let's just outlaw that!

Unfortunately the docs explicitly say the opposite, and people have
written code relying on it.

Havoc