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
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.
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.
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")
OpenScanHub [1] triggered this and flagged it as CWE-688 [2]:
common/flatpak-appdata.c:298:7: warning[-Wanalyzer-null-argument]: use
of NULL ‘parent’ where non-null expected
common/flatpak-appdata.c:282:6: branch_false: following ‘false’
branch...
common/flatpak-appdata.c:285:3: branch_false: ...to here
common/flatpak-appdata.c:285:3: branch_true: following ‘true’
branch...
common/flatpak-appdata.c:287:15: branch_true: ...to here
common/flatpak-appdata.c:289:6: branch_false: following ‘false’
branch...
common/flatpak-appdata.c:297:7: branch_false: ...to here
common/flatpak-appdata.c:297:6: branch_true: following ‘true’ branch
(when the strings are equal)...
common/flatpak-appdata.c:298:7: branch_true: ...to here
common/flatpak-appdata.c:298:7: danger: argument 1 (‘parent’) NULL
where non-null expected
# 296| /* avoid picking up <id> elements from e.g. <provides> */
# 297| if (g_str_equal (element_name, "id") &&
# 298|-> g_str_equal (parent, "component"))
# 299| {
# 300| component->id = g_steal_pointer (&text);
The parsing code doesn't throw any errors from G_MARKUP_ERROR. It
expects the input to be valid, and relies on assertions to express that.
eg., it asserts that a <component> element or tag is encountered before
any other, and particularly <content_attribute>, <content_rating> and
<release>.
In the same vein, an assertion was added to express that an <id> element
or tag always has a parent.
Spotted by Siteshwar Vashisht.
[1] https://openscanhub.dev/
[2] https://cwe.mitre.org/data/definitions/688.html
Several glibc functions now return a const pointer if the input is a const pointer and a non-const pointer if the input is non-const, causing a build failure.
Fix this by declaring the output pointers as const if they are never modified and for the lone failure where the output is modified instead make the input non-const.
What I did
Repository rules / “don’t edit” areas
From CONTRIBUTING.md and subprojects/README.md, subprojects/ contains vendored/submodule/copylib code (bubblewrap, libglnx, dbus-proxy, variant-schema-compiler). I treated subprojects/ as third-party and excluded it from typo fixing.
You already skip po/ (translations) and node_modules/, and I kept those exclusions.
Typos fixed (project-owned files only)
I ran codespell with write mode and exclusions, and fixed the reported typos across:
NEWS
app/…
common/…
doc/…
tests/…
session-helper/…
portal/…
data/…
Then I handled the remaining items individually:
NEWS: thse -> these
common/flatpak-utils-private.h: Thse -> These
app/flatpak-polkit-agent-text-listener.c: identies -> identities
tests/test-auth.sh: Propertly -> Properly
tests/testlibrary.c: remore -> remote
common/flatpak-transaction.c: improved wording to avoid the xwindows typo (X11 window ID)
Added .codespellrc
Created .codespellrc:
skip: node_modules,po,subprojects
ignore-regex: .*(ratatui|Affinitized|affinitized).*
ignore-words-list: nd,ot,THUR,IST,fo,hel,bu
(these were confirmed as legitimate tokens/abbreviations/namespace prefix/test strings in this repo, so they should not be “fixed”)
Verification:
codespell --config .codespellrc . now exits clean.
Signed-off-by: rezky_nightky <with.rezky@gmail.com>
While the arguments for --filesystem permissions either have to come
from a privileged source, or from the manifest which is supposed to be
checked by the remote, it was decided that paths are not allowed to move
up (..) a directory.
The check for this was both too complicated, and not sufficient, because
the special directories (e.g. xdg-download) might contain only a single
slash (xdg-download/..) and move one directory up.
This gives us conditionals for shares and features. So far we have no
use case for this, but the system already exists, it makes the code
simpler, and when we need this in the future, we don't have to wait for
it to roll out.
For device and socket the negated versions are nodevice and nosocket,
but for shares, the strings are allow and disallow. Take arguments for
both forms.
Allow specifying a lookside URL for downloading signatures for
an OCI remote. This can be specified:
In a .repofile with the SignatureLookaside key
As the --signature-lookaside option to remote-add/remote-modify
FlatpakOciSignature was a Flatpak-specific analog to
the containers/image "simple signatures" - but it wasn't used at
all, and Flatpaks on registry.redhat.io are signed by the
original simple signatures. So modify it correspond to
the original simple signatures.
