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

[Simon McVittie]

On Wed, 21 Feb 2007 at 12:18:49 -0500, John (J5) Palmieri wrote:
> On Wed, 2007-02-21 at 15:30 +0000, Simon McVittie wrote:
> > 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...
> 
> 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.

I find it strange that libdbus is happy to send messages with that object
path, if it's special within libdbus and causes bus disconnection!

To me it seems to violate least-astonishment to have such a reserved
object path. The reserved pseudo-bus-name is consistent with
org.freedesktop.DBus being the bus daemon, and is also in a namespace
(that of well-known bus names) where global uniqueness is obviously
necessary.

On the other hand, the namespace of object paths is local to the service,
which is perfectly within its rights to use paths like /docs/123 - I'd
understood the namespacing in object-path-space to be necessary only for
the case where the same bus connection is shared by e.g. multiple libraries?

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

"Broken applications that don't check the sender can believe they have
been disconnected when in fact they haven't" sounds to me like a bug in
those applications - depends on your point of view I suppose.

	Simon