could not connect to display :99.0 #3357
Comments
XAuthority isn't getting picked up for some reason. |
|
Removing |
|
Typically flatpak accessess the host display by bind-mounting in the unix domain socket for the xserver, which is generally Is the X socket still there? Sometimes it happens that it gets cleaned up by tmp cleaners, but other x apps keep working because there is also an abstract socket you can use (but not in a network namespace, so doesn't work for flatpak). |
|
I think I found the culprit. For some reason (I'm still trying to figure it out) I had Xvfb running and taking up display :99.0. After killing it I have no problems starting up the flatpak application. So I guess we can change the ticket to stop flatpaks from refusing to work when Xvfb is running. The command Xvfb was running with was
|
[citation needed], unfortunately. gdm does the equivalent of I discovered this when I made a Flatpak-like container environment unshare the UTS namespace and set a custom hostname, which I thought would be a nice way to tell at a glance which environment you're in. It worked fine on Debian + GNOME, but broke Manjaro + Plasma Desktop, because the magic cookie records in the XAUTHORITY file include a hostname, and the container and X server disagreed on which hostname they were looking for. |
I believe X servers on Linux normally listen on both the filesystem-based socket Abstract sockets seemed like a great idea in the 1990s - they're sockets, but you don't have to delete them from the filesystem when you've finished with them! - but they interoperate really badly with containers. D-Bus is gradually moving away from abstract sockets, and ideally X11 would too.
More specifically, "when Xvfb is running and is using display I'm not sure how Flatpak would achieve that. The only way I can think of would be to choose a display number and create a pair of (path-based, abstract) sockets on the host system just like Xvfb does (to see whether Xvfb is using it, and if not, claim it so that Xvfb cannot use it)... but then the application in the container would try to connect to the abstract socket on the host system, and we'd have to have a proxy to connect to the real X server and pass data backwards and forwards? If X displays have some sort of locking mechanism, then we could maybe claim a display number with that locking mechanism, but not actually create an abstract socket for it? Or perhaps just pick a very large number and hope nobody else uses it? (gdm does that: its "greeter" (login prompt) is on |
|
Another possible way to deal with this would be to use the same display number as on the host system, instead of 99. For instance, suppose your real display is
@alexlarsson, do you remember a reason why that approach couldn't be used? The only problem I can immediately see with this is that if, at some point in future, we wanted to put a proxy (like I think the long-term solution is for X11 on Linux to stop listening on abstract sockets, or possibly for X11 to disappear completely in favour of Wayland; but X11 has several decades of backwards-compat to consider, so that isn't going to happen any time soon. |
|
this can also be solved (mitigated) by runtime provides by removing abstract socket support from libxcb. need to remove this line here: https://gitlab.freedesktop.org/xorg/lib/libxcb/-/blob/master/configure.ac#L148 |
|
@yshui If you believe that should be done open an issue here describing in a bit of detail: https://gitlab.com/freedesktop-sdk/freedesktop-sdk |
Suppose the user's "real" X11 display on the host is Xorg or Xwayland listening on :42, but they also have an Xvfb server listening on :99. If we change the X11 display number to the arbitrary value :99, and the Flatpak sandbox shares its network namespace with the host, then clients inside the Flatpak sandbox will prefer to connect to the abstract socket @/tmp/.X11-unix/X99 (which is Xvfb), rather than the filesystem-backed socket /tmp/.X11-unix/X99 in the sandbox (which is really /tmp/.X11-unix/X42 on the host, i.e. Xorg or Xwayland). If they're relying on Xauthority (MIT-MAGIC-COOKIE-1) for access control (as many display managers do), then this will fail, because we gave the sandboxed app access to the cookies for Xorg/Xwayland (rewriting their display number from 42 to 99 as we did so), but Xvfb does not accept those cookies. If we're relying on `xhost +"si:localuser:$(id -nu)"` for access control (as gdm does), then the Flatpak app will successfully (!) connect to whatever is on :99, for example Xvfb or Xephyr, which is rarely what anyone wants either. Resolves: flatpak#3357 Signed-off-by: Simon McVittie <smcv@collabora.com>
Suppose the user's "real" X11 display on the host is Xorg or Xwayland listening on :42, but they also have an Xvfb server listening on :99. If we change the X11 display number to the arbitrary value :99, and the Flatpak sandbox shares its network namespace with the host, then clients inside the Flatpak sandbox will prefer to connect to the abstract socket @/tmp/.X11-unix/X99 (which is Xvfb), rather than the filesystem-backed socket /tmp/.X11-unix/X99 in the sandbox (which is really /tmp/.X11-unix/X42 on the host, i.e. Xorg or Xwayland). If they're relying on Xauthority (MIT-MAGIC-COOKIE-1) for access control (as many display managers do), then this will fail, because we gave the sandboxed app access to the cookies for Xorg/Xwayland (rewriting their display number from 42 to 99 as we did so), but Xvfb does not accept those cookies. If we're relying on `xhost +"si:localuser:$(id -nu)"` for access control (as gdm does), then the Flatpak app will successfully (!) connect to whatever is on :99, for example Xvfb or Xephyr, which is rarely what anyone wants either. Resolves: #3357 Signed-off-by: Simon McVittie <smcv@collabora.com>
Linux distribution and version
Kubuntu 18.04
I'm running Xorg and not Wayland. On Wayland it works, but unfortunately Wayland is not stable for me.
I have this issue running both on an Nvidia card and the integrated Intel one.
Flatpak version
1.6.0
Description of the problem
I cannot run any flatpak application. I always get
(Authenticator:2): Gtk-WARNING **: 14:02:31.983: cannot open display: :99.0or similar. This does not seem to be the same issue as #1821 because runningxhost +does not help.Trying to run Authenticator, a GTK app:
Trying to run Kube, a QT app:
The text was updated successfully, but these errors were encountered: