We were handling null properties the same as missing properties
*except* that the MANDATORY flag allowed null properties but
not missing properties. Fix this, so null is disallowed by
MANDATORY.
When checking signatures, the image identity could only have
been NULL if it was null in the input file - so replace a
conditional check on it being non-null with an assertion.
It's legitimate to have manifests listed in an image index that
have no platform object, and hence no architecture - avoid crashing
if we encounter such a manifest.
Mark all properties required by the OCI specification as required;
this eliminates a bunch of cases where we were assuming that
descriptor->digest was non-NULL, and potentially generating
critical errors from g_return_if_fail().
Both collect exports and flatpak_export_dir recursively export the
directories in their respective directory lists. Because of this,
including share/metainfo/releases when share/metainfo is already in the
lists is unnecessary and can cause exporting to fail because of
duplicate files.
Signature downloads can use a different URL from the OCI registry
itself, so they must not depend on TLS options left on the reused curl
handle. Resolve certificates for the URI and pass them explicitly.
Annotating the return as (transfer full) causes bindings to additionally
unref each element on array free, resulting in a use-after-free.
Change the annotation to (transfer container) so bindings know to unref
the array only.
Fixes: https://github.com/flatpak/flatpak/issues/6666
It was solved partially in e0e1b20, but not for completely disallowed code path.
Steps to reproduce:
1. Run any flatpak with explicit --unshare option, e.g:
[user@user-standardpc ~]$ flatpak run --unshare=network --command=bash io.gitlab.librewolf-community
2. Inside flatpak shell spawn any executable:
[io.gitlab.librewolf-community ~]$ flatpak-spawn ls /
Result is:
error: Unknown option --noshare=network
In flatpak_pull_from_oci we can be in in the system helper where we pull
the mirrored OCI image into the system repo. However, to fetch the
signatures in GPG signed repos, we used a remote OciImageSource created
through `flatpak_remote_state_fetch_image_source`. This caused fetching
some data from the registry which we don't want in the deploy method,
and also fails if a token is required to access the repo.
This change fetches the signatures from the mirrored OCI repo instead of
pulling them from the remote OciImageSource. The signatures can come from
anywhere because we verify them against the GPG key in the system repo.
The important bit is the change in `flatpak_pull_from_oci` where we now
pass in the local image_source to fetch the signatures from, and in the
system helper, where we get the right metadata to check the signatures
against (eventually ends up in `flatpak_oci_signatures_verify`).
Being unable to access the system-bus is nto a security boundry since,
in that case it's trivial to start your own session and set
DBUS_SYSTEM_BUS_ADDRESS. This is the same fix as 3afdfd2 but for handling
installation instead. See said commit for more details.
Adapted from #5609Fixes#5076
Co-authored-by: Dan Nicholson <dbn@endlessaccess.org>
/dev/kfd is used for AMD ROCm/OpenCL compute. Add it to the dri
device list so apps can request GPU compute access without
needing --device=all.
Fixes: https://github.com/flatpak/flatpak/issues/5383
I accidentally screwed up the arch I passed to a `flatpak update`
invocation and was very confused as to what actually went wrong. Adding
the actual refs in the commit should help make failure cause more
obvious.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
GTimeVal and g_get_current_time() are deprecated since GLib 2.62
and tv_sec is 32-bit on 32-bit platforms, causing Y2038 overflow.
g_get_real_time() returns gint64 and is safe on all platforms.
polkit_subject_to_string() is called inside the HAVE_LIBSYSTEMD guard
in flatpak_dir_log(), but <polkit/polkit.h> is only included when
USE_SYSTEM_HELPER is defined. This causes a build failure on
configurations that have libsystemd but no system helper.
Guard the polkit call with USE_SYSTEM_HELPER and fall back to "(none)"
so the subject string is always valid for the sd_journal_send() call.
Fixes: f9d5c5c ("dir: Free result of polkit_subject_to_string")
Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
If we convert fallback-x11 internally to a conditional x11 permission,
we cannot express current fallback-x11 stacking behavior:
lower: empty + upper: !fallback-x11 -> no x11 access
lower: fallback-x11 + upper: !fallback-x11 -> x11 access
The reason is that conditionals have no view of the lower level.
This changes things in a way that fallback-x11 stays its own socket
permission with two interactions with the x11 socket permission:
* If a upper level resets x11 (--socket=x11, --nosocket=x11), the lower
level fallback-x11 permission gets dropped
* When computing the allowed sockets, --socket=fallback-x11 gets
converted to --socket=if:x11:!has-wayland
Fixes: #6556
Ideally, we would be able to atomically add and remove remotes, but
we're very far from that ideal state. The current behavior is really
suboptimal and leaves the remotes in a inconsistent state if
initialization failed. We can at least make it better by trying to clean
up the half-initialized mess we're currently in. It does however not
protect against SIGKILL-like aborts, as that would require it to be
atomic.
Closes: #6449
Co-authored-by: craftyguy "Clayton Craft" <clayton@craftyguy.net>
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 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
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>
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>
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.
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
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.
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
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
