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
The code would always remove a pull from the hashtable, and then check if the
users match and abort if they don't. Either way, the pull gets dropped.
Fix this by only removing the pull if the dir and the user match.
We use flatpak_open_file_at in the context of the system helper to open
files written by a user. This means that we want to prevent DOS and
exposing files which only the system helper has access to.
To prevent DOS and avoid side-effects, the file is opened with
O_NONBLOCK and O_NOCTTY.
To prevent leaking files, the file is supposed to not open symlinks.
This part, we failed at. We check if the opened file is a regular file,
but what we actually checked is, if the file a symlink might point at is
a regular file.
Fix this by also specifying O_NOFOLLOW in openat.
The function flatpak_switch_symlink_and_remove is used to implement a
cache for ld.so (regenerate_ld_cache). If the active symlink changes to
a new cache file, the old cache file is supposed to get removed.
The symlink still points to the old cache file, so we would remove the
file that it points to and then point at the new file.
Because the symlink is under the app's control, the symlink can point
anywhere, and the removal happens in the host context, which allows an
app to remove arbitrary files on the host.
The filename of the cache files are checksums, which means that we can
ensure that the link is a file in the same directory of the link by
checking that it only contains the chars a-zA-Z0-9.
Now that flatpak_run_app accepts fds for app and runtime deploy, as well
as bind and ro-bind fds, and flatpak-run exposes the functionality, we
can finally hook this all up to the flatpak portal!
The flatpak portal allows apps to expose files and folders from within
the sandbox to a side-sandbox using flatpak-spawn. So far it has used
the --filesystem option to mount those files and folders, but it takes a
path. Paths are inherently racy and they allow the app to swap out any
component of the path with a symlink after handing it off. If they win
the race, flatpak will mount a completely different directory.
This adds a new way to mount files and directories based on O_PATH
file descriptor that needs to provided when execing the flatpak binary.
This also allows us to use glnx_chaseat, and other at-functions to
traverse the filesystem tree in a safe way.
This is important because the app and runtime deploy directories can be
under an attackers control. The flatpak portal for example allows
sandboxed apps to provide them.
In particular, attacks where the deploy dirs get replaced by a symlink
pointing into the host system will be stopped by this.
Note that this change alone is not enough to avoid the attack, and the
portal has to be changed as well.
We already have a function which clears a fd that a pointer points to,
so let's use it instead of duplicating the code.
Will become useful in a later commit as well.
This reverts commit c7824ae5f3.
We want to use the cgroup as authentication for flatpak instances in the
future. Giving explicit control over this to the user destroys the
invariant we need without a backwards incompatible change.
It seems to not expose any new capabilities and neither seems to greatly
affect the kernel attack surface, so let's just enable it
unconditionally.
If this turns out to be a bad decision, we can remove it again and maybe
guard it behind a new --device permission.
Closes: #6199
If the user presses any key while we the CLI transaction UI is being
shown, it ends up in stdin. When we issue the Cursor Position command,
the result is appended to stdin and we fail to match on it because of
the proceeding bytes.
Similarily, if we fail to match the command output (bad data, too slow,
..), we leave behind data in stdin which will be echoed back to the
terminal when we restore the initial termios which icnludes ECHO in
c_lflag.
Let's use TCSAFLUSH to flush out stdin data before we issue the command,
which should help with matching the expected response.
Let's also use TCSAFLUSH when we restore the previous termios to make
sure the stdin is clean and we don't echo whatever remains in stdin.
Closes: #2712
When an application or runtime is updated and its metadata requests a
new branch of an extension, Flatpak should automatically pull the new
branch if the user already has at least one branch of that extension
installed.
This ensures that "no-autodownload" extensions (like GIMP plugins)
stay functional after an update that requires a new branch, while still
respecting the user's explicit opt-in (the existing installation of
a previous branch).
Fixes: https://github.com/flatpak/flatpak/issues/4208
test-preinstall.sh was present in the generated test-matrix/meson.build
but missing from TEST_MATRIX_SOURCE in update-test-matrix, meaning it
would be dropped if the matrix were regenerated.
This overflows, which is undefined behaviour (in practice it will usually
wrap around into unsigned space, but this can't be guaranteed).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The 'arch' parameter of flatpak_dir_remote_fetch_indexed_summary() is
used to construct the names of the caches, and can't be NULL. This
function is used by flatpak_remote_state_ensure_subsummary(), which is
used by ensure_remote_state_arch(). So, the parameter can't be NULL in
those either.
Here are some strings representing valid refs:
app/org.test.App/x86_64/stable - full ref
org.test.App/x86_64/stable - full ref without prefix
org.test.App - only app ID
org.test.App/x86_64 - only app ID and arch
org.test.App//stable - only app ID and branch
Therefore, if a ref's prefix (ie., 'app/' or 'runtime/) is skipped,
then there can only be a maximum of 3 other elements in it.
Right now, it's possible for find_current_element() to return a count
of 4, if the string being completed is invalid and has some extra
elements or slashes in it. This count is later used to index the
cur_parts array which only has 4 elements in it. This opens up the
possibility of a buffer overrun.
Invalid strings with extra elements or slashes can't be further
completed because none of the existing refs will match them.
Therefore, such strings should be outright skipped.
For the rest of the valid strings, the exact intended branch name is
never known, because the branch element doesn't have a trailing slash
and hence appears to be a prefix. Therefore, it's not possible to use
the branch to find a list of existing refs that could possibly
complete the string.
Fallout from 7018717ce2
First of all, g_strcmp0() is NULL-safe, so there's no need to check if
ref_str is NULL or not.
Secondly, the NULL check triggers Coverity. It thinks that ref_str
might be NULL in the 'else' branch, where ref_str is unconditionally
accessed by flatpak_decomposed_new_from_ref(). There's no need to be
concerned about this because ref_str can't be NULL. It's one of the
parameters of the o.fd.Flatpak.SystemHelper.Deploy D-Bus method. It's
defined as an 's', and NULL is not a valid value for 's'. In fact,
this D-Bus argument is assumed to be not NULL when the Deploy method is
handled.
Fallout from 701602c6ca
As codified in flatpak_dir_get_remote_disabled(), a NULL URL caused by
a corrupt configuration file or a missing "url" key doesn't represent
a disabled remote. It's only disabled if ostree_repo_remote_get_url()
successfully returns an empty URL (ie., "").
It might be less confusing if the error messages are consistent with
this subtle difference.
Of the 27 instances where ostree_repo_remote_get_url() is used, these
are the only ones where the return value is ignored. This triggers
Coverity.
It might not always be strictly necessary to handle the errors, but
doing so can only help with debugging. However, in the case of
flatpak_dir_get_remote_disabled() this clarifies the subtle difference
between an empty URL (ie., ""), and a NULL URL caused by a corrupt
configuration file or a missing "url" key.
This was not a typo for "located": the daemon is systemd-localed,
or localed for short.
Fixes: bb549168 "fix: cross typos, detail below"
Signed-off-by: Simon McVittie <smcv@collabora.com>
We would get a reference to the old permission, then free it, and then
insert the freed pointer into the new hashtable again.
Closes: #6524
Fixes: 6667e1d3 ("context: Use the new permission system for shares and features")
