Unix FD Passing

Havoc Pennington hp at pobox.com
Wed May 20 15:13:42 PDT 2009


Hi,

On Wed, May 20, 2009 at 6:02 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> All that is needed is that both A and B verify that the connection
> they set up supports unix fd passing. I.e. the service provider should
> just bail our with an error early during startup if it is started on a
> bus that doesn't do unix fd passing. And similarly, the other side
> shouldn't try at all all to send requests with unix fds if they know
> their connection cannot do it.

The situation I have in mind is:

* bus has fd passing
* app A is some other dbus implementation than libdbus, or an older
libdbus, so no fd passing
* app B is using new libdbus with fd passing

When B tries to use some new API with an fd in the signature to talk
to A, that should give a runtime error reply.

I don't think we really need negotiation, just an error, as we'd do
for a security policy failure.

>> I was suggesting pretty much this except have the bus generate an
>> error rather than /dev/null, when eavesdrop=false ... this should be
>> fairly simple in the bus daemon, it's similar to what the bus daemon
>> does if a security policy forbids sending a particular message to a
>> particular app for example.
>
> I don't think this should return an error.
>
> After all, if you broadcast a signal you don't want to get zillions of
> responses from everyone who didn't understand it. Dropping messages
> silently should be good enough.

Signals don't generate replies from each recipient, so that won't come
up, just as it does not cause an error if there are apps on the bus
that are not allowed to get the signal due to security policy.

This can be handled exactly as with the security policy stuff afaict.
Error replies only arise when a reply would be sent in the first
place, which means only for method calls sent explicitly
(eavesdrop=false)

> I don't think this would be beneficial.
>

Silent fail when a reply was requested/expected is just wrong. The
method call sender would time out otherwise, which is sucky and makes
debugging pretty annoying.

It's very easy to just make this work nicely.

Havoc


More information about the dbus mailing list