Bug 246159 – [GTK] D-Bus proxy quietly fails if host bus address is not mounted in xdg-dbus-proxy's sandbox

• Component: WebKitGTK
• Status: RESOLVED FIXED

Created attachment 462838 [details]
strace of epiphany crashes

(Following through from https://github.com/WebKit/WebKit/pull/5011#issuecomment-1270291105)  

starting epiphany 43.0 with webkit2gtk 2.38.0 (gtk3+libsoup3 4.1 variant) and the above merge request yields the following crash loop trying to load any website (e.g. youtube.com):  

```
** (process:2): WARNING **: 17:48:07.176: Failed to connect to bus: Could not connect: No such file or directory

(WebKitWebProcess:2): Gdk-WARNING **: 17:48:07.176: Settings portal not found: Error receiving data: Connection reset by peer

** (process:2): WARNING **: 17:48:07.176: Failed to connect to bus: Could not connect: No such file or directory

** (process:2): WARNING **: 17:48:07.298: Failed to connect to bus: Could not connect: No such file or directory

(WebKitWebProcess:2): GLib-GIO-CRITICAL **: 17:48:07.298: g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

(epiphany:11328): epiphany-WARNING **: 17:48:07.310: Web process crashed

```

an strace of some of this is attached. from the strace, interestingly:  

12129 connect(8, {sa_family=AF_UNIX, sun_path="/tmp/dbus-DiTHLPEh5Q"}, 110) = -1 ENOENT (No such file or directory)

the DBUS_SESSION_BUS_ADDRESS is:

unix:path=/tmp/dbus-DiTHLPEh5Q,guid=0060023e9861265e5efb9ddc633ef48e  

this is with dbus 1.15.2 . the latest dbus releases now only support non-abstract sockets- prior to the change, the abstract sockets launched okay with the changes in the above merge request, and didn't work without it (crashed with either abstract or non abstract dbus)  

epiphany prior to 43 worked fine, because it didn't contain https://gitlab.gnome.org/GNOME/epiphany/-/commit/88cb0505cf55069f3aa36e50595cc2e32fc3bd38 which now does some extra things via libportal.  

the version of libportal is 0.6.0 and the version of xdg-dbus-proxy is 0.1.4

ah, and to add something i forgot- this is on alpine linux edge (dbus/webkit in question built myself), with a dbus session acquired with dbus-run-session -- sway

[Michael Catanzaro]

On your host system, is the socket /tmp/dbus-DiTHLPEh5Q or is it /tmp/dbus-DiTHLPEh5Q,guid=0060023e9861265e5efb9ddc633ef48e? I have not seen the ,guid= thing before and I suspect that is somehow causing trouble. Prior to 255218@main I would have guessed that we were not processing that properly; however, after that commit we now pass the session bus address along unchanged to xdg-dbus-proxy, so there's not really much room for us to mess things up. Hence, I suspect xdg-dbus-proxy might be doing something wrong.

> On your host system, is the socket /tmp/dbus-DiTHLPEh5Q or is it /tmp/dbus-DiTHLPEh5Q,guid=0060023e9861265e5efb9ddc633ef48e?  

it's the former. i don't actually know where the latter comes from, or what it means  

shell output:
```
< echo $DBUS_SESSION_BUS_ADDRESS 
unix:path=/tmp/dbus-dWAkZgPPf8,guid=931566075287f0624096a0ff633eff69
< ls -l /tmp/dbus-dWAkZgPPf8 
srwxrwxrwx 0 demon  6 Oct 18:16 /tmp/dbus-dWAkZgPPf8
```

> Hence, I suspect xdg-dbus-proxy might be doing something wrong.  

i do have the webkit commit in question for this testing, so yeah, sounds likely. if there's anything specific you want me to test/patch, i can give it a spin.

[Michael Catanzaro]

The spec https://dbus.freedesktop.org/doc/dbus-specification.html says:

"""
Server addresses consist of a transport name followed by a colon, and then an optional, comma-separated list of keys and values in the form key=value. 
"""

And:

"""
A server may specify a key-value pair with the key guid and the value a hex-encoded 16-byte sequence. the section called “UUIDs” describes the format of the guid field. If present, this UUID may be used to distinguish one server address from another. A server should use a different UUID for each address it listens on. For example, if a message bus daemon offers both UNIX domain socket and TCP connections, but treats clients the same regardless of how they connect, those two connections are equivalent post-connection but should have distinct UUIDs to distinguish the kinds of connection.

The intent of the address UUID feature is to allow a client to avoid opening multiple identical connections to the same server, by allowing the client to check whether an address corresponds to an already-existing connection. Comparing two addresses is insufficient, because addresses can be recycled by distinct servers, and equivalent addresses may look different if simply compared as strings (for example, the host in a TCP address can be given as an IP address or as a hostname).

Note that the address key is guid even though the rest of the API and documentation says "UUID," for historical reasons.
"""

We were indeed not handling that properly, but I accidentally/incidentally fixed it inn 255218@main. So next step is to look at what xdg-dbus-proxy does with that address.

[N4t3R]

bash-5.2$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/tmp/dbus-hXi1NB31ch,guid=4ab95a17b8d702fa34692bd7633e9533

[Michael Catanzaro]

oreo639 found the problem. We run xdg-dbus-proxy in mostly the same sandbox that the web process runs under so it doesn't have access to host /tmp, only to /run. We need to make sure it can see the session bus wherever it is.

[N4t3R]

Awesome

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #4)
> We were indeed not handling that properly, but I accidentally/incidentally
> fixed it in 255218@main.

Nah, I just didn't look closely enough. It was handled fine.

[Michael Catanzaro]

The a11y bus has the same problem. Carlos fixed this in 246957@main, but accidentally reintroduced the issue in 254293@main, which has not been released yet.

[Michael Catanzaro]

Pull request: https://github.com/WebKit/WebKit/pull/5136

[EWS]

Committed 255530@main (67cda4acff9b): <https://commits.webkit.org/255530@main>

Reviewed commits have been landed. Closing PR #5136 and removing active labels.