Package: flatpak Version: 1.8.5-1 Severity: important Tags: upstream fixed-upstream Forwarded: https://github.com/flatpak/flatpak/issues/4286 Control: found -1 1.2.5-0+deb10u2
In the flatpak-portal service in flatpak >= 1.8.5-1, when a Flatpak app launches a subsandbox (a separate container for part of itself, perhaps with more restrictions or a different runtime library stack) using flatpak-spawn --env=... --forward-fd=... or equivalent D-Bus calls, depending on the specific file descriptors passed to --forward-fd=..., they might collide with the temporary fd used to transfer the environment variables. If this happens, the subsandbox will either fail to start, or run with unintended environment variables. Minimal(ish) manual test: in one terminal run /usr/libexec/flatpak-portal -vr and in another terminal run flatpak run --command=bash org.gnome.Weather -euxc \ 'echo 15 > /tmp/15; echo 16 > /tmp/16; echo 17 > /tmp/17; while flatpak-spawn --env=FOO=bar --forward-fd=15 --forward-fd=16 --forward-fd=17 sh -euxc "$1" 15</tmp/15 16</tmp/16 17</tmp/17; do :; done' \ sh \ 'test "$FOO" = bar; test "$(cat <&15)" = 15; test "$(cat <&16)" = 16; test "$(cat <&17)" = 17' (You can substitute any app that runs on a recent-ish runtime for org.gnome.Weather, it doesn't actually matter which app is used.) Ignore lines of output that say "F: ioctl(0, TIOCSCTTY, 0) failed: Operation not permitted"; these are harmless. Good result: it loops until terminated with Ctrl+C. Bad result: "error: Environment variable must be given in the form VARIABLE=VALUE, not 16". This reproducer works for 1.10.2 on Debian 11, but the exact numbers needed to trigger the bug might be different in different versions. smcv