Bugzilla – Bug 1219962
Custom libxcb patch causes infinite loop on Xwayland
Last modified: 2024-03-06 15:46:08 UTC
The openSuSE libxcb package ships with a custom patch: https://build.opensuse.org/package/view_file/openSUSE:Factory/libxcb/n_If-auth-with-credentials-for-hostname-fails-retry-with-XAUTHLOCALHOSTNAME.patch?expand=1 This causes an infinite loop when you try connecting to X as root. In particular, this happens quite frequently when running `zypper`-related operations, for example if a postinstall script decides to call `xset fp rehash`. Sometimes zypper also likes to call `dbus-launch`, which resolves to `dbus-launch.x11`. Attempting to run `xcb_connect` as root, with this patch, results in an infinite loop of the following error: Authorization required, but no authorization protocol specified This happens because the branch at line 134 gets hit with `c->has_error == true` and `stage == 1`, which then does `goto retry`. The next iteration of the loop results in the exact same error, with `stage` never being incremented to `2` as intended. I'm not sure why. To reproduce, simply run `sudo xset fp rehash` under Xwayland; specifically, I'm using Hyprland, but probably any other wlroots-based compositor (or perhaps any Wayland compositor) will suffice.
See also https://github.com/hyprwm/Hyprland/issues/4716
These patches have a longer history. ------------------------------------------------------------------- Sat Aug 26 14:44:23 UTC 2023 - Stefan Dirsch <sndirsch@suse.com> [...] - adjusted bug-262309_xcb-xauthlocalhostname.diff, n_If-auth-with-credentials-for-hostname-fails-retry-with-XAUTHLOCALHOSTNAME.patch [...] ------------------------------------------------------------------- Fri Jan 5 10:44:07 UTC 2018 - msrb@suse.com - n_If-auth-with-credentials-for-hostname-fails-retry-with-XAUTHLOCALHOSTNAME.patch * Prevent infinite loop also in case DISPLAY is non-local. [...] ------------------------------------------------------------------- Wed Dec 20 21:07:38 UTC 2017 - aaronpuchert@alice-dsl.net [...] - n_If-auth-with-credentials-for-hostname-fails-retry-with-XAUTHLOCALHOSTNAME.patch * If authentication (with *stage == 0) failed and the variable XAUTHLOCALHOSTNAME wasn't set, we were never getting to stage 2 in the original patch, causing calls to xcb_connect_to_display to be stuck in an infinite loop. Now we also go to stage 2 if the variable isn't set. [...] ------------------------------------------------------------------- Thu Nov 30 15:11:43 UTC 2017 - msrb@suse.com - n_If-auth-with-credentials-for-hostname-fails-retry-with-XAUTHLOCALHOSTNAME.patch * Modify this patch to do what it say - retry not only if the current hostname is not found in the xauthority file, but also when it is rejected by X server. (bnc#1043221) [...] ------------------------------------------------------------------- Wed Dec 23 23:16:43 UTC 2015 - eich@suse.com - n_If-auth-with-credentials-for-hostname-fails-retry-with-XAUTHLOCALHOSTNAME.patch: If auth with credentials for hostname fails retry with XAUTHLOCALHOSTNAME (boo#906622). [...] ------------------------------------------------------------------- Fri Apr 27 11:16:25 CEST 2007 - sndirsch@suse.de - bug-262309_xcb-xauthlocalhostname.diff: * add code, which checks for XAUTHLOCALHOSTNAME now also for libxcb, since Xtranssock.c has been replaced by XCB as transport layer (Bug #262309)
Ok. I can reproduce this when running gnome-terminal on a GNOME/Wayland session. ~> echo $XDG_SESSION_TYPE wayland ~> sudo DISPLAY=:0 glxinfo -B Authorization required, but no authorization protocol specified Authorization required, but no authorization protocol specified Authorization required, but no authorization protocol specified [...]
The problem stems from the fact that "XAUTHLOCALHOSTNAME" is unset (`sudo` strips it from the environment). This causes it to never hit the branch that sets `*stage` to 2. Most likely, the intent here was to always increment `*stage`, even on failure.
Yeah. By adding XAUTHLOCALHOSTNAME to Defaults env_keep = "..." line of /usr/etc/sudoers, the result is: ~> sudo DISPLAY=:0.0 glxinfo -B Authorization required, but no authorization protocol specified Authorization required, but no authorization protocol specified Error: unable to open display :0.0
Fabian found the culprit ... *** This bug has been marked as a duplicate of bug 1221078 ***
This error condition is only relevant if the X11 connection fails, so something already went wrong before. In the case here it appears like sudo is configured to forward $DISPLAY but not other parts necessary for a working X11 connection. That's a config issue.