Why DESTINATION?

[Felipe Gasper]

> On Feb 21, 2019, at 12:52 AM, Thiago Macieira <thiago at kde.org> wrote:
> 
> On Wednesday, 20 February 2019 20:52:18 PST Felipe Gasper wrote:
>>> On Feb 20, 2019, at 11:37 PM, Thiago Macieira <thiago at kde.org> wrote:
>>> 
>>> On Monday, 18 February 2019 04:31:43 PST Lennart Poettering wrote:
>>>> So, it's relevant when a client sends a message, but it's indeed not
>>>> too interesting when a client recvs a message.
>>> 
>>> A client could (but should not) do some kind of "name virtual host" by
>>> reacting differently depending on the called service name.
>> 
>> Actually, I don’t think that’s possible because of the behaviour being
>> described: dbus-daemon doesn’t pass the called service name to the
>> recipient; the DESTINATION that dbus-daemon sends is just the recipient’s
>> unique name. The recipient has no way to know what name the sender gave as
>> DESTINATION.
> 
> dbus-daemon DOES pass the called service name to the recipient.
> 
> Quick proof by stracing plasmashell and trying to introspect shows:
> 
> 2427  recvmsg(8, {msg_name=NULL, msg_namelen=0, 
> msg_iov=[{iov_base="l\1\0\1\0\0\0\0\2\0\0\0\207\0\0\0\1\1o\0\1\0\0\0/
> \0\0\0\0\0\0\0\6\1s\0\23\0\0\0org.kde.plasmashell\0\0\0\0\0\2\1s\0#\0\0\0org.freedesktop.DBus.Introspectable\0\0\0\0\0\3\1s\0\n\0\0\0Introspect\0\0\0\0\0\0\7\1s\0\6\0\0\0:1.362\0\0", 
> iov_len=2048}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, 
> MSG_CMSG_CLOEXEC) = 152
> 
> Decoding each byte is left as an exercise for the reader. But do note the 
> "org.kde.plasmashell" in the middle of the data, which can't be anything but a 
> service name.

Interesting. I tried something similar just now, and that’s what I see, too. Maybe I read the wrong monitoring data earlier.

Anyway, thank you!

-F