Unix FD Passing

[Havoc Pennington]

Hi,

On Wed, May 20, 2009 at 4:30 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> 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.

Right, but we don't have a way to feature negotiate over the bus; apps
A and B talking by bus are unable to negotiate.

Wow this is a thorny can of worms if you think about it too much. Say
old d-feet introspects a new app that has fd support, it will get
introspection data with an unknown type in it, for example.

Seems we need a runtime error if the bus is in the middle, but can do
return_if_fail when check_supports_type() works

> 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.

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.

In fact in the same spot that calls the "check security policy"
functions, we could add "check feature compatibility" and do this
exactly the same way.

Havoc