/org/freedesktop/DBus/Local in message header causes disconnect - why?!

[Simon McVittie]

I was recently asked to track down a dbus-python crash triggered by
using dbus-inspector to introspect trackerd. It turns out that trackerd
advertises /org/freedesktop/DBus/Local in its introspection XML; when
dbus-inspector obediently tries to introspect that object, it is
disconnected by the bus daemon.

Looking at the message validation code, it seems that this object path
is somehow reserved, and the bus daemon will respond to any message with
this in its object path header field by kicking the process that sent it
off the bus.

Since object paths are local to a service, having globally reserved
object paths seems rather broken - as far as I'm aware, the only
significance of Local is that the Disconnected signal comes from the
pseudo-bus-name org.freedesktop.DBus.Local, path
/org/freedesktop/DBus/Local. The pseudo-bus-name is enough to
identify messages mistakenly sent to Local, the object path surely
doesn't need to be reserved too...

If this path really does need to be reserved for some reason, the
specification should say so, and libdbus and all reimplementations
(dbus-java, dbus-sharp) should prohibit making method calls on it or
emitting signals from it.

Currently /org/freedesktop/DBus/Local is not mentioned in the spec,
and this issue is not handled in (at least) libdbus, the bindings to GLib
and Python, or the reimplementations dbus-java and dbus-sharp.

Thoughts?

	Simon