[Bug]: Lock file of wayland socket is not passed through

[ilya-fedin]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.
• If this is an issue with a particular app, I have tried filing it in the appropriate issue tracker for the app (e.g. under https://github.com/flathub/) and determined that it is an issue with Flatpak itself.
• This issue is not a report of a security vulnerability (see here if you need to report a security issue).

Flatpak version

1.14.0

What Linux distribution are you using?

NixOS

Linux distribution version

22.11.19700101

What architecture are you using?

x86_64

How to reproduce

tdesktop uses QtWaylandCompositor to create a nested compositor for web bots, the library checks lock files to find a free socket name, but flatpak doesn't passes through the lock (i.e. wayland-0, but not wayland-0.lock). QtWaylandCompositor thus assumes the socket is free and tries to listen it, crashing the application and preventing all subsequent launch of the application

Expected Behavior

flatpak passes through both the socket and associated lock file

Actual Behavior

flatpak passes through only the socket

Additional Information

No response

[smcv]

tdesktop uses QtWaylandCompositor to create a nested compositor for web bots, the library checks lock files to find a free socket name

Regardless of whether this is solved by something like #5195 or not, it would be safer to create special-purpose compositors with a namespaced name so that they don't accidentally get used by normal applications. If you're running an X11 desktop environment, you presumably don't want ordinary GTK or Qt applications to see your special-purpose nested compositor create $XDG_RUNTIME_DIR/wayland-0, think "oh good, Wayland is available!" and start displaying on your special-purpose nested compositor instead of on the global X11 display...

Gamescope is an example of a special-purpose compositor used to run games (its Wayland compositor intentionally doesn't have ordinary desktop-oriented interfaces, only the minimum that's required to run a full-screen Xwayland), and it uses $XDG_RUNTIME_DIR/gamescope-%d (where %d is some integer) instead of $XDG_RUNTIME_DIR/wayland-0.

[ilya-fedin]

It seems to be quite problematic as if I specify custom socket name, I will lose the library's logic to automatically detect the first free socket as I see only API to set socket name rather than socket namespace in QtWaylandCompositor. wayland-server doesn't seem to have anything like that either, wl_display_add_socket_auto doesn't accept a prefix.

[ppaalanen]

For the reason @smcv mentioned, I believe most Wayland compositors, special or not, intentionally do not use the wayland-0 socket. Or at least they should not. WAYLAND_DISPLAY environment variable is the way to find the socket for a client to connect to.

But even then, if everyone skips wayland-0 and starts probing from wayland-1, the same problem with (lack of) lock files would happen. Calls to wl_display_add_socket() need the lock file to see if it's already taken.