Why DESTINATION?

[Thiago Macieira]

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.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products