Unix FD Passing

[Lennart Poettering]

On Wed, 20.05.09 16:16, Havoc Pennington (hp at pobox.com) wrote:

Hi,

> > 4) dbus_connection_send_with_reply() -- this is the special case. It
> > doesn't have a way to signal proper error codes synchronously (except
> > OOM), but at least it has a way to distuingish OOM from other errors
> > (OOM returns FALSE, non-OOM returns TRUE and sets *pending_return to
> > NULL).
> >
> > Only case 4) is what this discussion is about, right? There are the
> > two options to a) make it work like dbus_connection_send() and just
> > fail synchronously or b) make it succeed, return a proper
> > DBusPendingCall but then immediately synthesize an error message on
> > that async function call object, i.e. make it fail asynchronously.
> >
> > Sending an unix fd on a connection that cannot handle it is not a
> > typical runtime error, it is a (local) programming error.
> 
> Thinking out loud for a minute:
> 
> If we want to say this, then the correct answer would be
> _dbus_return_if_fail() rather than silent failure or an error reply
> message.

You have a point there.

> A problem, though, is that it isn't strictly backward compatible. For
> example, dbus-daemon would start to break in this case because it
> might receive an fd-containing message from app A that supports fds,
> and then try to route it to app B that does not support fds.
> 
> What should happen in that case I think is that app A would get an
> error reply back "app B does not support fds" probably. (Only if app B
> was the destination, vs. an eavesdropper.)
> 
> That is, generally app A and B are talking through the bus; so
> dbus_connection_can_send_type() will generally return true, but that
> does not mean the message will be understood by app B. Maybe this is a
> more general issue that the bus needs to intercept any message that
> the recipient won't be able to handle and return an error on behalf of
> the recipient. That implies that inherently, when adding feature
> negotiation, something that forwards around messages like dbus-daemon
> cannot be kept working without modification. Feature negotiation
> simply is not back compat in the bus daemon scenario.

Hmm, not sure if I fully agree here.

After all it is as much a programming error to expose an API that
needs unix fd passing on a connection that doesn't support it as it is
trying to make use of such an API via a connection doesn't support it.

i.e. on a connection that cannot support it expecting an unix fd is
as broken as sending an unix fd.

> If we say that we're breaking ABI for this situation, then we may as
> well just go for the _dbus_return_if_fail(). But this does raise the
> issue that we have to fix the bus daemon to send back an error if app
> A uses a feature not supported by app B.

A possible solution could be to use _dbus_return_if_fail() in
dbus_connection_send() and friends and then simply fix the dbus daemon
to not forward messages that include unix fds on connections that
don't do it. That would be simple and make a lot of sense to me.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4