Skip to content

Fix regression when exported filesystem objects are symlinks or have symlink ancestors

Simon McVittie requested to merge wip/smcv/sr518 into master

  • exports: Add flatpak_debug2() logging at a finer granularity

    This helps to figure out what is going on if the expected paths are not being exported.

  • pv-wrap: Don't use fd-relative I/O for Flatpak-derived exports code

    When I added support for a mock root file descriptor in FlatpakExports, it was as design-for-test rather than for production use, so it is not as thorough as the rest of pressure-vessel about resolving symlinks in the mock root: some code paths will escape from the mock root, while others will detect the escape and raise an error. Because this is code that we share with Flatpak, we can't make it behave like the rest of pressure-vessel unless we either diverge from Flatpak (increasing maintenance cost), or copy _srt_resolve_in_sysroot() into Flatpak (difficult to justify when Flatpak has no need for the increased complexity).

    Unfortunately, this is causing regressions when launching Steam games when an exported filesystem path, or an ancestor or parent of an exported filesystem path, is an absolute symbolic link. This was not detected during development because the majority of exported filesystem paths are either inside the home directory, inside the Steam library, or inside ~/.steam, which are usually "real directories" with all of their ancestors up to the root also being "real directories", resulting in their contents not needing to be exported explicitly.

    The FlatpakExports code detects that the absolute symlinks encountered in this situation are "escaping" from /proc/self/fd/N/, and behaves as though the symlink did not exist, causing important Steam objects to fail to appear inside the container. For example, if ~/.steam is a symbolic link, then symlinks like ~/.steam/root will be missing, breaking parts of the Steamworks API.

    We don't actually need to alter FlatpakExports' behaviour even in the FEX-Emu case, because after converting the FlatpakExports object into a sequence of bwrap arguments, we remap those arguments through adjust_exports(), which handles the possibility that a path that is apparently in the root filesystem is really in the FEX-Emu sysroot. We do that because we need it for pv_bwrap_share_sockets(), which calls into Flatpak-derived code that does not support specifying an alternative root, but it'll work equally well for non-socket objects like ~/.steam.

    This partially reverts commit 5c3fb090.

    Fixes: 5c3fb090 "pv-wrap: Bypass FEX-Emu overlay for most top-level directories"
    Resolves: https://github.com/ValveSoftware/steam-runtime/issues/518

The second commit probably also fixes https://github.com/ValveSoftware/steam-runtime/issues/517, and maybe https://github.com/ValveSoftware/steam-runtime/issues/516 (it's less clear whether 516 is a single issue or multiple issues).

To do (not a merge blocker): upstream the first commit to Flatpak.

Merge request reports