If _flatpak_dir_ensure_repo is called with allow_empty=true, it is
allowed to fail to create the repo, and is supposed to return success in
that case.
The system helper handles this correctly, but we then call to
ensure_repo_opened no matter if the repo actuall exists and return an
error when it does not, no matter if allow_empty is set or not.
Closes: #6618
This gets rid of the test-matrix generation, and instead enumerates all
the tests in meson.
Some people (including me) constantly modified the generated meson
instead of the test-matrix generator file because they find it so
uncommon and unusual that a meson file is generated.
This looses the combinatorial combination of the generated system, but
in practice, six lines of enumeration is not bad, and it makes things
easier to understand.
This can be used by apps to restrict access to `--device=usb` by using
the portal and falling back to `--device=usb` if it is not available:
--device-if=usb:!has-usb-portal
Closes: #6557
This can be used by apps to restrict access from `--device=all` to
`--device=usb` in a backwards compatible way:
--device-if=all:!has-usb-device --device=usb
Closes: #6557
Before this change, the hash table was populated with the keyfile as key
and value, but the lookup and invalidate was done on the sender as the
key.
We never found a previous sender, and never invalidated one.
Fix this by actually using the sender as the key.
test-run-custom.sh was only manually appended to test-matrix/meson.build
and would be lost on regeneration. Add it to update-test-matrix so it is
properly managed.
This is functionally equivalent to the local child_setup() deleted by
this commit, except that it ignores lseek() errors, which can
legitimately happen when inheriting a non-seekable file descriptor.
Since commit ac62ebe "run: Use O_PATH fds for the runtime and app
deploy directories", any extra-data helper that runs inside a runtime
will receive a non-seekable O_PATH fd as its /usr.
Resolves: https://github.com/flatpak/flatpak/issues/6608
Signed-off-by: Simon McVittie <smcv@collabora.com>
Now that we're passing the app's /app and /usr down to bwrap as O_PATH
file descriptors, it will be even more common to have non-seekable fds
in the array.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These fds are stdin, stdout and stderr respectively, and are expected
to remain open at all times (if they are not needed then they can point
to /dev/null, but they should always be open). If the user gives us
`--env-fd=2` or similar, we don't want to close fd 2 before exiting
unsuccessfully: that would give us nowhere to display the error message.
Signed-off-by: Simon McVittie <smcv@collabora.com>
When repair (re)installs runtimes via a transaction, the transaction
auto-pins every runtime it touches. This causes repair --reinstall-all
to pin every installed runtime, cluttering the pin list with runtimes
that were never explicitly pinned by the user and preventing
flatpak remove --unused from cleaning them up.
Fix this by disabling auto-pinning on the repair transaction so that
the pin state is left exactly as it was before the repair.
Fixes https://github.com/flatpak/flatpak/issues/6565
flatpak-run takes a number of arguments which are file descriptor
numbers. Those file descriptors are supposed to set something up in the
way the instance gets spawned, but should never make it to the wrapper
command.
When we run `tests/test-run-custom.sh` as a build-time test,
we expect to already have the necessary runtimes, apps, etc. in
`${builddir}/tests/runtime-repo`. However, when running "as-installed"
tests, we're using a fresh temporary ostree repo for each test.
Merely having the repo exist is not enough: for some tests, and in
particular `tests/test-run-custom.sh`, it needs to have more than one
runtime available.
Resolves: https://github.com/flatpak/flatpak/issues/6591
Signed-off-by: Simon McVittie <smcv@collabora.com>
As with the previous commit, historically we would debug-log but
otherwise silently ignore attempts to expose a file in a sandboxed
subsandbox that doesn't have a suitable path.
For example, org.gnome.Epiphany (or possibly WebKitGTK) asks to expose
files from /app and /usr in the subsandbox. When we ignored those
requests (because /app and /usr have a different meaning on the host
system), the app worked as intended anyway, because the subsandbox has
access to the app's /app and the runtime's /usr whether they're
explicitly added or not, so it all worked out OK. However, treating
this as a fatal error (as it arguably should have been) broke
Epiphany's subsandboxes.
Fixes: 3c500145 "portal: Use --bind-fd, --app-fd and --usr-fd options to avoid races"
Resolves: https://github.com/flatpak/flatpak/issues/6584
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
For the sandbox expose fds, a historical quirk of this code is that if
the checks in get_path_for_fd() failed, we would merely log at g_info()
level (usually only shown when debugging the portal), and otherwise
silently ignore the request to expose the fd in the sandbox.
With hindsight this was probably not the right thing to do, but apps
could well be relying on it now. For example, there are indications
that Epiphany might send a memfd from the main instance to a subsandbox,
which never actually worked, but will break that subsandbox process
if that's treated as a fatal error.
Fixes: 3c500145 "portal: Use --bind-fd, --app-fd and --usr-fd options to avoid races"
Helps: https://github.com/flatpak/flatpak/issues/6584
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
If the handle is not in the range `0 <= handle < fds_len`, but no
GError is set, we'd have crashed when we dereferenced error->message.
Instead, log an error and early-return, matching what we do for
app-fd, usr-fd and the array of inheritable fds.
Fixes: 3c500145 "portal: Use --bind-fd, --app-fd and --usr-fd options to avoid races"
Helps: https://github.com/flatpak/flatpak/issues/6584
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
This was originally in flatpak-portal, then was duplicated into
flatpak-run in commit ac62ebe3 "run: Use O_PATH fds for the runtime and
app deploy directories", and subsequently removed from the portal in
commit 3c500145 "portal: Use --bind-fd, --app-fd and --usr-fd options to
avoid races". Now we want to use it in the portal again.
Helps: https://github.com/flatpak/flatpak/issues/6584
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
On entry to `flatpak run`, these fds have been inheritable (not
FD_CLOEXEC), otherwise they would not have been inherited; but we don't
want the "payload" command to inherit them, so set them as
non-close-on-exec as soon as we receive them. In the cases where we pass
them down to the underlying bwrap command, we'll either dup them, or
set them to be inheritable again (in practice we dup them).
In particular, Chromium-derived web browsers get very upset when their
subsandbox processes inherit unexpected fds, which has been causing crashes
with no useful diagnostic information since CVE-2026-34078 was fixed.
Fixes: 1b5e886d "run: Add --usr-fd and --app-fd options"
Fixes: b5ae89ed "run: Add --(ro-)bind-fd options"
Resolves: https://github.com/flatpak/flatpak/issues/6582
Signed-off-by: Simon McVittie <smcv@collabora.com>
org.freedesktop.Platform.openh264 is one example of an extension that
runs a statically-linked extra-data helper, with no runtime. Only open
the runtime if there is one.
Fixes: ac62ebe3 "run: Use O_PATH fds for the runtime and app deploy directories"
Resolves: https://github.com/flatpak/flatpak/issues/6583
Signed-off-by: Simon McVittie <smcv@collabora.com>
When FlatpakDir runs extra-data helpers in apply_extra_data(),
if the helper is statically linked, it might not need a runtime at all.
For example the helper for openh264 falls into this category.
Fixes: ac62ebe3 "run: Use O_PATH fds for the runtime and app deploy directories"
Helps: https://github.com/flatpak/flatpak/issues/6583
Signed-off-by: Simon McVittie <smcv@collabora.com>
fd_map_remap_fd() is called several times after this, and without this
change it can allocate a target fd that collides with instance_id_fd.
Only the write end of the pipe needs to be considered because that's
the one passed to the child.
Closes: https://github.com/flatpak/flatpak/issues/6570
This is only moving it a bit down because
flatpak_run_add_environment_args still adds a whole bunch of binds which
then can over-mount the user requested binds (bind-fd, ro-bind-fd).
Calls to flatpak_bwrap_add_args_data_fd take ownership over the fd they
take. Closing them while they are still in the bwrap struct will abort
later when the bwrap struct gets freed and it tries to close the already
closed fd.
Fix this by using glnx_autofd and g_steal_fd.
The data field of a GArray is a gchar* but we're storing integers
here, so use the proper method to ensure that we're getting the
element at the right offset and with the correct type.
Before addressing CVE-2026-34078, we would always mount the original app
*somewhere*, either /app (in the normal case) or /run/parent/app (when
using a custom or empty /app for the subsandbox). The empty-app case
regressed during the fix for CVE-2026-34078; bring back previous behaviour.
Fixes: ac62ebe3 "run: Use O_PATH fds for the runtime and app deploy directories"
Resolves: https://github.com/flatpak/flatpak/issues/6568
Signed-off-by: Simon McVittie <smcv@collabora.com>
In flatpak_run_app(), the else-if branch that handles
FLATPAK_RUN_APP_DEPLOY_USR_ORIGINAL was checking custom_app_fd instead
of custom_runtime_fd. When custom_app_fd is APP_EMPTY (-3) and
custom_runtime_fd is USR_ORIGINAL (-2), the condition would not match
and fall through to g_assert_not_reached(), aborting the process.
This broke sub-sandbox spawning with --app-path="" (empty app), which
is used by steam-runtime-check-requirements to verify that Flatpak's
sub-sandbox mechanism works.
Fixes: ac62ebe3 "run: Use O_PATH fds for the runtime and app deploy directories"
Helps: https://github.com/flatpak/flatpak/issues/6568
