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

John (J5) Palmieri johnp at redhat.com
Wed Feb 21 09:18:49 PST 2007


On Wed, 2007-02-21 at 15:30 +0000, Simon McVittie wrote:
> 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.

The reason why you are kicked off the bus is that D-Bus assumes you are
trying to spoof the bus.  It is reserved by the libdbus and should not
be used.  We should add it to the spec.  Basically
org.freedesktop.DBus.Local and /org/freedesktop/DBus/Local signify that
the message is coming from the application itself.  Some applications,
however broken, can check for just the object path and it would be a
security risk if any application could send a disconnected signal to
another application.

-- 
John (J5) Palmieri <johnp at redhat.com>



More information about the dbus mailing list