register object path + introspection

[Havoc Pennington]

Hi,

2010/7/16 Rémi Denis-Courmont <remi at remlab.net>:
> I assume "the process" mean the DBus connection.
> What prevents it from matching the destination (call) or sender (signal,
> reply)?

The destination isn't useful because in many proper usages, the
destination will be the unique bus name, not the well-known one. The
sender is always the unique name so that isn't useful either. Really,
the bus should strip out the destination field once it routes a
message, it doesn't just for efficiency reasons, but using this field
in the receiving process is wrong.

Yes, dbus could have been designed such that the object path and the
bus name were combined - basically, it could have been designed such
that you registered *objects* on the bus instead of *processes
containing objects*. However, it wasn't designed that way and doesn't
work that way, so trying to use it that way breaks.

One advantage of the current design is that it allows tons of objects,
including "on-demand created" or "virtual" objects, efficiently. For
example it is viable to support
/spreadsheets/worksheet1/row5324/col1788 as an object path, where the
app would never actually create an object per-spreadsheet-cell, but
just handle messages. Or another example is having every widget in a
UI be exported as a tree of objects. The idea was to avoid a giant
hash table of tons of objects having to be kept in sync between the
bus daemon and the apps.

> To me, it looks more like naming a member of a class "foo".

You're thinking the bus name refers to an object, but it does not. It
refers to a process that contains N objects.

Just because MPRIS only defines one object, doesn't mean that the same
process implementing MPRIS only wants to have one object.

> On Lennart's blog, you wrote:
> "The bus name is about routing the message, it should never  affect how the
> message is processed, by either sender or receiver. There is already an
> object path and an interface and a method name used to decide how to
> process the message."
>
> But if it is only about routing, then how would the receiver of a signal or
> reply ascertain the identity of the sender? You can't trust every process
> on the bus not to "fake" object paths, especially on the system bus, can
> you?

You can securely identify the sending process; you are trusting the
sending process to be accurate about the object path (and about the
event the signal represents). i.e. the bus provides the
guaranteed-correct identity of the sending process, but the bus isn't
guaranteeing anything about what that process sends (other than, it
came from the process it says it came from).

The system bus security policies can be used to ensure that only
certain users can own certain bus names and things like that, to help
ensure the process you're talking to is trusted.

Havoc