[Bug]: subsandbox chooses extensions independently of original app

[smcv]

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.

Flatpak version

1.12.2

What Linux distribution are you using?

Debian

Linux distribution version

unstable

What architecture are you using?

x86_64

How to reproduce

1. Run an app in a way that alters the extensions we use, for example FLATPAK_GL_DRIVERS=mesa-git flatpak run com.valvesoftware.Steam
2. In that app, use flatpak-spawn (or Steam's pressure-vessel-launch, which uses the same D-Bus API) to start a new subsandbox, and do not use --latest-version or FLATPAK_SPAWN_FLAGS_LATEST_VERSION

Expected Behavior

The subsandbox has the same /app, /usr and extensions as the original app, at the same commits.

If using #4018 via pressure-vessel-launch, then the expected result is that /run/parent/app and /run/parent/usr are the same as the original app's /app and /usr, including all extensions; for example if the original app has mesa-git mounted below /usr, then the subsandbox has mesa-git mounted below /run/parent/usr.

Actual Behavior

As expected, flatpak-portal tells flatpak run to use the same exact commit as the original app's /app for the subsandbox's /app or /run/parent/app.

As expected, flatpak-portal tells flatpak run to use the same exact commit as the original app's /usr for the subsandbox's /usr or /run/parent/usr.

However, flatpak-portal does not tell flatpak run to use the same extensions and extension commits as the original app's extensions (and in fact there is no mechanism to do so), so flatpak run will compute which extensions to mount from first principles. In particular, the GL stack below /run/parent/usr in the subsandbox will be the default GL stack, even if the original app was forced to use a non-default GL stack.

This leads to ValveSoftware/steam-runtime#474, because pressure-vessel (SteamLinuxRuntime) relies on the graphics stack in the original app (Steam) matching the graphics stack in the subsandbox that it creates.

Additional Information

From source code inspection, there is another, closely related, failure mode. If you run an app, leave it running, and upgrade some of its extensions before creating the subsandbox, the desired result is that the subsandbox gets the old versions of the extensions (matching the original app), but the actual result is that the subsandbox gets the new (upgraded) versions.

I've started to look into solving this by using the FLATPAK_METADATA_KEY_APP_EXTENSIONS and FLATPAK_METADATA_KEY_RUNTIME_EXTENSIONS from the /.flatpak-info to populate the subsandbox's list of extensions, but it isn't straightforward to match them to extension points, so it's going to need some more work and I don't have a MR ready yet.

[smcv]

Resolving #5278 would solve 95% of this, and might be easier than the approach I had started working on.