mirror of
https://github.com/flatpak/flatpak.git
synced 2026-03-27 19:33:06 -04:00
6b1b2cc804
As described in #5614, `WAYLAND_SOCKET` provides a single-use socket as a file descriptor, which some Wayland compositors use to track special-purpose Wayland clients like input methods and panels. Since #5615, there are two cases for how it works: 1. With `--nosocket=inherit-wayland-socket` (default): the file descriptor is marked close-on-exec so that the sandboxed app does not inherit it, and the `WAYLAND_SOCKET` environment variable becomes unset. Every time the sandboxed app connects to Wayland, because `WAYLAND_SOCKET` is unset, it will fall back to the ordinary, public `WAYLAND_DISPLAY`. 2. With `--socket=inherit-wayland-socket`: the file descriptor is allowed to be inherited, and the environment variable continues to be set. The first time the sandboxed app connects to Wayland, it will connect to the `WAYLAND_SOCKET`. The second and subsequent connection attempts will be to the ordinary `WAYLAND_DISPLAY`. However, when #4920 added a code path for the Wayland security-context-v1 interface, it was implemented as a completely separate code path which early-returned from flatpak_run_add_wayland_args() before the point where #5615 subsequently added the implementation for (1.). The practical result of this is that if the compositor sets `WAYLAND_SOCKET` for a Flatpak app, and it also happens to implement security-context-v1, then the application will always inherit the `WAYLAND_SOCKET` as though `--socket=inherit-wayland-socket` had been used. In this case, the app's first connection to Wayland will use the `WAYLAND_SOCKET` (bypassing the security context mechanism), the same as in compositors that do not implement security-context-v1 at all, and only the second and subsequent connections will use the special per-app `WAYLAND_DISPLAY` created by the security context mechanism. This seems likely to be unexpected. To give maintainers and users a choice between behaviours (1.) and (2.), we can put the security-context-v1 code path through the same code to handle `WAYLAND_SOCKET` that is used for Wayland compositors that do not implement that interface. This means that `--nosocket=inherit-wayland-socket` disables `WAYLAND_SOCKET` in all cases: if the compositor supports security-context-v1 and the feature was also available when Flatpak was compiled, then all of the sandboxed app's Wayland connections will be to the per-app `WAYLAND_DISPLAY` created by security-context-v1, and otherwise all of the sandboxed app's Wayland connections will be to the ordinary, public `WAYLAND_DISPLAY`. With `--socket=inherit-wayland-socket`, the sandboxed app's first connection to Wayland will continue to be to the inherited `WAYLAND_SOCKET` fd, and the second and subsequent connections will be to the `WAYLAND_DISPLAY`, which might either be the special per-app version created by security-context-v1, or the ordinary public version. Signed-off-by: Simon McVittie <smcv@collabora.com>