Unix FD Passing

[Havoc Pennington]

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.

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.

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.

Havoc