Signal doesn't go through xdg-dbus-proxy if unique connection name is specified as destination

[ilya-fedin]

tdesktop uses dbus for its IPC. Whenever it needs to create a webview, it spawns a child process that initializes webkit2gtk (Qt initializes gtk as well, so if they initialize different gtk versions (qt may initialize gtk2 while tdesktop initializes gtk3), the process will crash, so it's going on in a separate process), then main process calls methods and subscribes to signals on service of the child process. Child process checks for connection ID to be equal to parent process connection ID when it gets a request to a method, signals have parent connection ID as destination as well. The check in method calls works just fine, but signals don't go to the destination in flatpak for some reason :(. I think xdg-dbus-proxy is the cause of this weird behavior, IPC works just fine if I run the package with --socket=session-bus.

[davin67]

[davin67]

[smcv]

This also affects the experimental "steamrt3c" version of the Steam client beta when run via the unofficial Flatpak app. The new Steam client communicates between different parts of itself using a D-Bus interface similar to the ones used by flatpak-spawn, so that code running inside a container (that is not intended to be a security boundary) can run diagnostic commands etc. outside the container. In this case the server is steam-runtime-launcher-service --alongside-steam in the original Flatpak container, and the client is, for example, steam-runtime-launch-client --alongside-steam -- lspci in a Flatpak "subsandbox".

I was able to make it work by using a modified steam-runtime-launcher-service that sends ProcessExited (its equivalent of SpawnExited and HostCommandExited in flatpak-spawn) as a broadcast, instead of as a unicast, when it detects that it's running inside Flatpak.

I think it would make sense for a unicast signal (destination != NULL) to be essentially equivalent to a method call with NO_REPLY_EXPECTED, so it goes through whenever the sender is allowed to "talk" to the recipient.

It looks as though this might already be meant to work, but unicast signals are quite subtle, so it isn't particularly surprising if something has gone wrong somewhere.

[smcv]

I think it would make sense for a unicast signal (destination != NULL) to be essentially equivalent to a method call with NO_REPLY_EXPECTED, so it goes through whenever the sender is allowed to "talk" to the recipient.

Ah, possibly the problem here is that Flatpak apps are not automatically allowed to "talk" to other instance of the same Flatpak app, because there's no good way to tell that the recipient is that Flatpak app, unless it happens to own a bus name that proves that it is. If that's the case, then one solution would be to give the Flatpak app --own-name for some suitable class of bus names (for example the Steam Flatpak app already has --own-name=com.steampowered.*), and then make the client request a bus name in that namespace during startup, so that the server can send back a unicast signal to it in response, and xdg-dbus-proxy can know (based on name ownership) that the signal is meant to be allowed.