| Summary: | [GTK] D-Bus proxy quietly fails if host bus address is not mounted in xdg-dbus-proxy's sandbox | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | alice | ||||
| Component: | WebKitGTK | Assignee: | Michael Catanzaro <mcatanzaro> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | bugs-noreply, mcatanzaro, michael, naterussell83 | ||||
| Priority: | P2 | ||||||
| Version: | Other | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=245843 | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 206533 | ||||||
| Attachments: |
|
||||||
|
Description
alice
2022-10-06 08:56:54 PDT
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 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. 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. bash-5.2$ echo $DBUS_SESSION_BUS_ADDRESS unix:path=/tmp/dbus-hXi1NB31ch,guid=4ab95a17b8d702fa34692bd7633e9533 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. Awesome (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. 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. Pull request: https://github.com/WebKit/WebKit/pull/5136 Committed 255530@main (67cda4acff9b): <https://commits.webkit.org/255530@main> Reviewed commits have been landed. Closing PR #5136 and removing active labels. |