"Invalid client serial" when used with xdg-dbus-proxy

[mid-kid]

Hi, I was trying to use Jetbrains Toolbox with xdg-dbus-proxy, and I encountered an issue with your library.

Specifically, if xdg-dbus-proxy's --filter option is being used, the app will hang on startup for about 5-10 minutes before continuing. Meanwhile, xdg-dbus-proxy spits out the following message:

** (process:10596): WARNING **: 21:28:17.026: Invalid client serial

steps to reproduce

Download the Jetbrains Toolbox app, then run the following:

xdg-dbus-proxy "$DBUS_SESSION_BUS_ADDRESS" "$HOME/dbus" --filter --log &
DBUS_SESSION_BUS_ADDRESS="unix:path=$HOME/dbus" ./jetbrains-toolbox

Full xdg-dbus-proxy log:

C1: -> org.freedesktop.DBus call org.freedesktop.DBus.Hello at /org/freedesktop/DBus
B1: <- org.freedesktop.DBus return from C1
B2: <- org.freedesktop.DBus signal org.freedesktop.DBus.NameAcquired at /org/freedesktop/DBus
C3: -> all signal com.canonical.Unity.LauncherEntry.Update at /

** (process:15395): WARNING **: 12:49:58.552: Invalid client serial

temporary workaround

run jetbrains-toolbox like this instead:

./jetbrains-toolbox --appimage-extract && cd squashfs-root
rm lib/dbus-java-transport-native-unixsocket-4.0.0.jar
APPDIR="$PWD" APPIMAGE="$HOME/.local/share/JetBrains/Toolbox/bin/jetbrains-toolbox" DBUS_SESSION_BUS_ADDRESS="unix:path=$HOME/dbus" ./AppRun

This causes the app to never connect to dbus, bypassing the hang.

cross-linked issues

flatpak/xdg-dbus-proxy#45
netblue30/firejail#5265

[hypfvieh]

Sorry I don't get it...
What are you trying to do and where is it related to dbus-java?
What is xdg-dbus-proxy and why should I use it?
Which version of dbus-java is involved here?
Are you using it as client or is it running the embedded dbus?

Edit
Removing the transport will cause dbus-java to do nothing. Without a transport it will be unable to connect to DBus.

[mid-kid]

xdg-dbus-proxy is a utility used for separating apps that use dbus from the rest of the system, giving them only access to the specific services that they need. It creates its own dbus server and connects to the system's dbus server to proxy and filter calls. This is incredibly useful for any kind of sandboxing technology, such as flatpak and firejail.

I am trying to get an app that uses dbus-java to run inside a sandbox whilst using xdg-dbus-proxy to restrict its access from most dbus services. My current trail of debugging has led me towards this library, as removing its transport jar changes the result of the execution, causing it to not connect to dbus at all, instead of hanging. I mention this as a "fix" since I don't rely on its dbus functionality, I just want the app to run.

The version of dbus-java involved, according to the jar files in jetbrains-toolbox, is 4.0.0.

[hypfvieh]

Is there any sort of log produced by dbus-java? Usually dbus-java uses Slf4j with any slf4j compliant logger to log what's going on. Especially turning on TRACE-logging would definitely help to find out what is going on.

[mid-kid]

I have no idea how to do that.

[hypfvieh]

Are you sure you are xdg-dbus-proxy the correct way?
Just using --filter will cause xdg-dbus-proxy to block all communication except for the initial handshaking to DBus.
See here.

When using xdg-dbus-proxy and a patched version of jetbrains-toolbox (with logging enabled) I can see that dbus-java connects to the Bus for the handshaking stuff, but as soon as jetbrains-toolbox want to listen to signals of com.canonical.Unity.LauncherEntry the signal is not being answered and the socket is closed.
For me it looks like if there are missing a lot of options for xdg-dbus-proxy to tell the proxy to allow talking to com.canonical.Unity.LauncherEntry and may others as well.

[mid-kid]

I wasn't able to tell which dbus services it was trying to access, but yeah I reckon it needs a few whitelists to work. Still, I don't have a com.canonical.Unity.LauncherEntry on my system, so it should have the same behavior here? And if DBUS_SESSION_BUS_ADDRESS is set to some bogus value like "foo", it gracefully and silently fails as well..

[hypfvieh]

This has to do with the exception handling of the calling code.
When DBus is not available dbus-java will instantly fail with an AddressResolvingException or an IOException. When the calling code swallows the exception, nothing will happen (no DBus usage, no blocking).

When blocking certain calls the problem is different. While establishing connection to DBus worked (handshaking, sending Hello etc), specific calls get blocked. In that case the connection (at least in version 4.0.0) gets into some sort of half-disconnected behaviour, which causes the connection to be treated as connected when it actually isn't.
This was fixed in 4.1.0 of dbus-java.

When using 4.1.0 with your setup, the application will only block for about 10-20 seconds due to waiting for method replys which will never be received.

I improved this in the latest 4.1.1 snapshot, so dbus-java will no longer wait for method-replies if the disconnection from the bus was caused by an IOException (e.g. of the transport like in this case).

The error message 'invalid client serial' you see is not from dbus-java but from some launcher used to start the jetbrains-toolbox.
I guess that this has something to do with messages not arriving at that application, but usually this does not hurt.

[mid-kid]

Thanks a lot for digging into this issue! Glad to know the mechanics of all of this now. It makes sense, as xdg-dbus-proxy works in a way many applications don't expect, but I guess I was confused since I've never seen similar behavior in other programs using dbus. Many thanks for implementing a workaround anyway, I'll be patiently waiting for that to trickle downstream :)

And yeah, the "Invalid client serial" message comes from xdg-dbus-proxy itself: https://github.com/flatpak/xdg-dbus-proxy/blob/main/flatpak-proxy.c#L2182-L2190
I wrongly assumed that would be the issue since I didn't see this message pop up during correct operation. It might not be related at all.