Package: flatpak Version: 1.8.5-1 Severity: important Tags: upstream fixed-upstream Control: found -1 1.2.5-0+deb10u2
The flatpak-portal service in flatpak >= 1.8.5-1 leaks a file descriptor every time 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=... or equivalent D-Bus calls. Minimal reproducer: in one terminal run /usr/libexec/flatpak-portal -vr and in another, run flatpak run --command=bash org.gnome.Weather -euxc \ 'while flatpak-spawn --env=FOO=bar sh -euxc "$1"; do :; done' \ sh \ 'test "$FOO" = bar' (org.gnome.Weather is just an example, it can be any app). Terminate the flatpak run loop with Ctrl+C after a few seconds. Ignore lines of output that say "F: ioctl(0, TIOCSCTTY, 0) failed: Operation not permitted"; these are harmless. Good result: in the flatpak-portal -vr output, you see the same --env-fd= every time. Bad result: the number after --env-fd= keeps going up. The real-world impact is that if Flatpak apps launch enough subsandboxes, the subsandbox interface will stop working for the rest of the login session, causing other Flatpak apps to fail to work. Chromium is a notable example of a Flatpak app that uses subsandboxes. smcv