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>
(cherry picked from commit c14ad37229)
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>
(cherry picked from commit aa1a54c9da)
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>
(cherry picked from commit fde4716f67)
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
(cherry picked from commit 066babba75)
We use local_open_file 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.
(cherry picked from commit FIXME)
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.
(cherry picked from commit FIXME)
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.
Sudo can be used in several ways other than calling a command with the
root user. For example, one can use -u to run the command as the
specified user, or -g to specify a primary group to run the command
as.
Flatpak adds a check when --user is used to prevent an installation in
the root's directory, for example, but it does it by only checking if
sudo was used. As stated previously, it does not necessarily imply
root, so this patch explicitly checks if the command is being run with
the root user.
Fixes: https://github.com/flatpak/flatpak/issues/5979
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
(cherry picked from commit f61d931da8)
When an xdg dir is not available, it is supposed to point at $HOME. We
do not want to mount $HOME though in that case, so we just skip the xdg
dir instead.
The check compares the strings of the the xdg dir path and the home dir
path. So far it relied on the functions internally canonicalizing the
paths in the same way, but there was a glib regression:
https://gitlab.gnome.org/GNOME/glib/-/issues/3811
("g_get_user_special_dir doesn't strip trailing slash from $HOME")
Which then was fixed in cb3e9fe74 ("gutils: Strip all trailing
slashes").
We can however just canonicalize on the paths on the caller side to make
this more robust, so let's just do that.
Closes: #6323
(cherry picked from commit bb2d517bb1)
Xe module supports the discrete and new integrated GPUs (the Arc series) and
the i915 supports the older Intel integrated GPUs (Intel HD).
Closes: https://github.com/flatpak/flatpak/issues/5248
(cherry picked from commit f53cef0041)
Fixes#2489
Adds and wires up a `reinstall` option to
`flatpak_dir_install_bundle`. Previously, bundle install
transactions would silently drop the reinstall flag.
(backported from commit 919d2922bf)
Instead of using flatpak_oci_manifest_descriptor_get_ref which requires
the `org.opencontainers.image.ref.name` annotation, get any valid
manifest, and make sure to return NULL if there are multiple valid
manifests.
Closes: https://github.com/flatpak/flatpak/issues/6081
(cherry picked from commit 3773617f30)
If an SDK is already installed in a dir that is not targeted with a
flatpak transaction, and the transaction has auto_install_sdk set,
add_new_dep_op returns NULL in dep_op which is not correctly handled in
add_deps.
Fixes#5894
(cherry picked from commit c4af112df4)
Without doing so, flatpak_dir_get_config() won't reflect changes made
with flatpak_dir_set_config().
This fixes passing multiple patterns to `flatpak mask` for the system
installation.
Closes#5464
(cherry picked from commit a7ac4206c6)
Fixes c75ba1c7e1
```
In file included from /usr/lib/aarch64-linux-gnu/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:34,
from /usr/include/glib-2.0/glib/galloca.h:34,
from /usr/include/glib-2.0/glib.h:32,
from /usr/include/glib-2.0/gobject/gbinding.h:30,
from /usr/include/glib-2.0/glib-object.h:24,
from /usr/include/glib-2.0/gio/gioenums.h:30,
from /usr/include/glib-2.0/gio/giotypes.h:30,
from /usr/include/glib-2.0/gio/gio.h:28,
from ../common/flatpak-utils-http.c:23:
In function ‘glib_autoptr_clear_GFileEnumerator’,
inlined from ‘glib_autoptr_cleanup_GFileEnumerator’ at /usr/include/glib-2.0/gio/gio-autocleanups.h:69:1,
inlined from ‘flatpak_get_certificates_for_uri’ at ../common/flatpak-utils-http.c:284:34:
/usr/include/glib-2.0/glib/gmacros.h:1361:10: warning: ‘enumerator’ may be used uninitialized [-Wmaybe-uninitialized]
1361 | { if (_ptr) (cleanup) ((ParentName *) _ptr); } \
| ^
/usr/include/glib-2.0/glib/gmacros.h:1379:3: note: in expansion of macro ‘_GLIB_DEFINE_AUTOPTR_CLEANUP_FUNCS’
1379 | _GLIB_DEFINE_AUTOPTR_CLEANUP_FUNCS(TypeName, TypeName, func)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/gio/gio-autocleanups.h:69:1: note: in expansion of macro ‘G_DEFINE_AUTOPTR_CLEANUP_FUNC’
69 | G_DEFINE_AUTOPTR_CLEANUP_FUNC(GFileEnumerator, g_object_unref)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../common/flatpak-utils-http.c: In function ‘flatpak_get_certificates_for_uri’:
../common/flatpak-utils-http.c:284:34: note: ‘enumerator’ was declared here
284 | g_autoptr(GFileEnumerator) enumerator;
```
(cherry picked from commit cd0212aa40)
Docker and podman can be configured to use mutual TLS authentication
to the registry by dropping files into system-wide and user
directories. Implement this in a largely compatible way.
(Because of the limitations of our underlying libraries, we
can't support multiple certificates within the same host config,
but I don't expect anybody actually needs that.)
The certs.d handling is extended so that certificates are separately
looked up when downloading the look-aside index. This is mostly
to simplify our tests, so we can use one web server for both -
in actual operation, we expect the indexes to be unauthenticated.
Also for testing purposes, FLATPAK_CONTAINER_CERTS_D is supported
to override the standard search path.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
The systemd Desktop Environments conventions for cgroup names is
app[-<launcher>]-<ApplicationID>-<RANDOM>.scope
where RANDOM should ensure that multiple instances of the application
can be launched. Currently flatpak uses the PID of itself but the
instance fullfills this convention and is a bit more useful for matching
the cgroup to a flatpak instance.
There are cases where flatpak is doing some internal work (apply extra
data) where there is no instance id, and more philosophically also no
app instance. In those cases we simply do not move the process to the
cgroup with the XDG convention.
The original idea behind this code was that the initial lockless scan
of reachable objects will make the locking one fast enough that
it won't matter to software managing flatpak repos like flat-manager.
Few years later I can say this is not true, and the locking variant
of scan does take too long and affects Flathub's publishing process.
By keeping only the lockless variant in dry run, we can run it on a
weekly schedule without affecting operations, and issue actual pruning
with flat-manager which will hold a lock in external system and avoid
executing any actions requiring locking to avoid errors/timeouts.
Currently, app installs and updates are treated the same from the point
of view of the parental controls permissions checks. This was intended so
that parents have to re-check each app update to make sure it’s still
appropriate for their children.
In practice, though, parents are not that hands-on, and there are a lot of
regular app updates. The tradeoff between app updates (which bring
security fixes and features) and not changing so much in apps that a
parent’s initial assessment of their suitability for their child is
probably skewed the wrong way. We should be preferring updates (in
particular, so we get security updates), and assuming that if an app is
OK to begin with, it’s probably not going to change so radically as to
become unsuitable for a child with an update.
As a data point, Google Play’s parental controls will allow apps to be
automatically updated even if a child account can’t install new apps.
So, implement this by splitting the existing
`org.freedesktop.Flatpak.override-parental-controls` polkit action in
two: the existing action for _installs_, and a new
`org.freedesktop.Flatpak.override-parental-controls-update` action for
_updates_. `FlatpakDir` is changed to use the appropriate action
depending on whether an app is being installed from scratch or updated.
The default policies for the two actions differ.
Users/Distros who disagree with the new default policy can provide their
own polkit rules to change the behaviour of
`override-parental-controls-update` so that it matches
`override-parental-controls`, to bring back the old behaviour.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: https://github.com/flatpak/flatpak/issues/5552
udmabuf allows clients to allocate virtual memory as dmabufs,
which then potentially can be imported by other dma subsystems -
most importantly GPU drivers and KMS. This can avoid copies and
thus increase performance.
Unlike other dmabuf allocators like e.g. dma heaps this doesn't
have known issues relevant for sandboxing. Notably memory accounting
works as expected, so apps can't use udmabuf to escape resource
limitations. For this reason systemd, since version 257[1], grants
"uaccess" access to udmabuf by default, considering it as "safe".
With udmabuf increasingly being availably by default, various apps
and libraries start making use of it - examples include libcamera,
mesa llvmpipe and Gstreamer. Thus let's grant access to it in Flatpak
as well.
For now limit it to "dri" access as sharing buffers with GPUs is
the most common use-case. There is no strong reason to not lift
restrictions further if the need arises, though.
1: https://github.com/systemd/systemd/pull/33738
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Robert Mader <robert.mader@collabora.com>
In the real at-spi2-core client library, AT_SPI_BUS_ADDRESS is treated
as higher-precedence than the AT_SPI_BUS X11 atom or the GetAddress()
D-Bus method. Mimic this.
We don't currently implement querying the X11 atom because that would
require a libX11 dependency, so leave a comment indicating where it
would appear in precedence order.
Signed-off-by: Simon McVittie <smcv@collabora.com>
To handle those details at the right place (flatpak-run-wayland.c), we
pass if the wayland socket is allowed to flatpak_run_add_wayland_args
and handle it there instead of in the caller.
Closes#3948
Static libraries do not carry information about their dependencies.
Thus, libflatpak_dep must include all of the dependencies for
libraries to link against libflatpak. To do this, I've repurposed the
libflatpak_common_deps variable, which previously was either empty or
contained only wayland_client, and was then included into the list of
dependencies for libflatpak-common, to be a list of all dependencies
required to both build libflatpak-common, and link against it (or
libflatpak).
This fixes building Flatpak with -Ddefault_library=static. gtkdoc
must currently be disabled due to a Meson bug I'm working on[1].
[1]: https://github.com/mesonbuild/meson/pull/14257
The ostree and Flatpak APIs both refer to "end of life", but
this internal #define (though not the data stored in the cache)
refer to "end of line".
Fix this.
This is a new warning. Reproducible on F41
Fixes:
../common/flatpak-installation.c:1963: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:1858: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2129: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2014: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:1732: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2177: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2220: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2608: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
Signed-off-by: Hubert Figuière <hub@figuiere.net>
Instead of hardcoding /var/tmp when temporarily downloading layer
tarballs, support overriding with a FLATPAK_DOWNLOAD_TMPDIR
environment variable.
We don't use TMPDIR because the layer tarballs can be very big
(in extreme cases like an SDK > 1GB), and TMPDIR is more
likely to point to a in-memory tmpfs.
Now that we read remotes from $datadir/flatpaks/remotes.d as well as
/etc/flatpaks/remotes.d, we should have a mechanism to redirect this, as
we do for almost all other filesystem path locations.
To avoid an explosion of new variables, we introduce FLATPAK_DATA_DIR to
represent configuration that ships with the operating system.
This is useful:
- To fix sandboxing of tests
- When installing using flatpak into a chroot, so that we read
the chroot's configuration rather than the host.
It also is used when reading triggers, but the current
FLATPAK_TRIGGERSDIR is left for compatibility.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
As described in #5614, `WAYLAND_SOCKET` provides a single-use socket
as a file descriptor, which some Wayland compositors use to track
special-purpose Wayland clients like input methods and panels.
Since #5615, there are two cases for how it works:
1. With `--nosocket=inherit-wayland-socket` (default): the file
descriptor is marked close-on-exec so that the sandboxed app does
not inherit it, and the `WAYLAND_SOCKET` environment variable
becomes unset. Every time the sandboxed app connects to Wayland,
because `WAYLAND_SOCKET` is unset, it will fall back to the ordinary,
public `WAYLAND_DISPLAY`.
2. With `--socket=inherit-wayland-socket`: the file descriptor is
allowed to be inherited, and the environment variable continues
to be set. The first time the sandboxed app connects to Wayland,
it will connect to the `WAYLAND_SOCKET`. The second and subsequent
connection attempts will be to the ordinary `WAYLAND_DISPLAY`.
However, when #4920 added a code path for the Wayland security-context-v1
interface, it was implemented as a completely separate code path which
early-returned from flatpak_run_add_wayland_args() before the point
where #5615 subsequently added the implementation for (1.). The practical
result of this is that if the compositor sets `WAYLAND_SOCKET` for
a Flatpak app, and it also happens to implement security-context-v1,
then the application will always inherit the `WAYLAND_SOCKET` as though
`--socket=inherit-wayland-socket` had been used. In this case, the app's
first connection to Wayland will use the `WAYLAND_SOCKET` (bypassing
the security context mechanism), the same as in compositors that do not
implement security-context-v1 at all, and only the second and subsequent
connections will use the special per-app `WAYLAND_DISPLAY` created by the
security context mechanism. This seems likely to be unexpected.
To give maintainers and users a choice between behaviours (1.) and (2.),
we can put the security-context-v1 code path through the same code to
handle `WAYLAND_SOCKET` that is used for Wayland compositors that do not
implement that interface. This means that
`--nosocket=inherit-wayland-socket` disables `WAYLAND_SOCKET` in all
cases: if the compositor supports security-context-v1 and the feature
was also available when Flatpak was compiled, then all of the sandboxed
app's Wayland connections will be to the per-app `WAYLAND_DISPLAY`
created by security-context-v1, and otherwise all of the sandboxed app's
Wayland connections will be to the ordinary, public `WAYLAND_DISPLAY`.
With `--socket=inherit-wayland-socket`, the sandboxed app's
first connection to Wayland will continue to be to the inherited
`WAYLAND_SOCKET` fd, and the second and subsequent connections will
be to the `WAYLAND_DISPLAY`, which might either be the special per-app
version created by security-context-v1, or the ordinary public version.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In the older code path where we were not using Wayland security contexts,
we would try to preserve the name of the Wayland display socket
(`$WAYLAND_DISPLAY`), only falling back to `wayland-0` if the name was
something unconventional (contains `/` or does not start with `wayland-`).
This means that in practice, apps could often successfully use a value
of `$WAYLAND_DISPLAY` from the wrong "world" - for example reading the
value used outside the sandbox from a file in code that runs inside the
sandbox, or conversely, passing the value used inside the sandbox via
IPC to a service like gpg-agent outside the sandbox.
However, the implementation in
flatpak_run_add_wayland_security_context_args() did not do this, and
instead would unconditionally use `wayland-0`. There's no real need to
enforce use of that name.
Apps should not really be passing the string value of `WAYLAND_DISPLAY`
across a sandbox boundary, but in practice some do, and we will get
better interoperability if we try to keep that working in at least the
simple cases. This is similar in spirit to how we have handled X11
since 2022 (flatpak/flatpak#5034).
For now, we skip the last few lines of flatpak_run_add_wayland_args() if
we are using Wayland security contexts, to preserve existing
functionality. A subsequent commit will revisit that.
Resolves: https://github.com/flatpak/flatpak/issues/5863
Signed-off-by: Simon McVittie <smcv@collabora.com>
apply_extra_data() passes a null instance ID to
flatpak_run_add_environment_args(), causing a segfault in
flatpak_run_in_transient_unit() which assumes the instance ID is non-null.
Revert this for now: flatpak#5962 was non-essential, and we can redo it
in a less crashy way later.
This reverts commit 7d6f3e8b6b.
Resolves: https://github.com/flatpak/flatpak/issues/6009
Signed-off-by: Simon McVittie <smcv@collabora.com>
Add '--usb' and '--nousb' to the FlatpakContext option group.
Map these parameters to either the enumarable list, or the hidden
list, of a new "USB Devices" group in the metadata key file. It looks
like this:
```
[USB Devices]
hidden-devices=cls:01:*;
enumerable-devices=vnd:0fd9+dev:0080;vnd:0fd9+dev:0080;
```
Flatpak itself does not use these values, they're meant to be used
by e.g. XDG Desktop Portal to filter which devices the app can see
through the USB portal.
Hidden devices must always take precedence over enumerable devices.
This is heavily inspired by https://github.com/flatpak/flatpak/pull/4083
Co-Authored-By: Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
Co-Authored-By: Ryan Gonzalez <rymg19@gmail.com>
Signed-off-by: Hubert Figuière <hub@figuiere.net>
The systemd Desktop Environments conventions for cgroup names is
app[-<launcher>]-<ApplicationID>[@<RANDOM>].service
where RANDOM should ensure that multiple instances of the application
can be launched. Currently flatpak uses the PID of itself but the
instance fullfills this convention and is a bit more useful for matching
the cgroup to a flatpak instance.
Simon McVittie