This is a step towards removing the libostree dependency from
flatpak-utils, which should be one of the lowest-level components.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This breaks the circular dependency between flatpak-utils and flatpak-dir.
There is still a circular dependency between flatpak-dir and
flatpak-dir-utils, but I don't want to make flatpak-dir even larger.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is a step towards making flatpak-utils conceptually "smaller"
than all other translation units, with no dependencies beyond GLib and
libglnx. In particular, consolidating all the OCI registry manipulation
into one place means we can build other translation units without
libarchive.
This would also be a step towards being able to provide a build-time
option to build a libostree-only version of Flatpak without the OCI
feature or the direct libarchive dependency, if someone wanted to
implement that.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These signals can be used by apps to monitor whether they need to emit
signals on the a11y bus or not. This can very significantly reduce
chattery on the a11y bus, and at least WebKit relies on these signals
to be broadcasted in.
The PR https://github.com/flatpak/xdg-dbus-proxy/pull/61 is required
for this changeset to work as expected, but it can land independently
as `--broadcast` is supported by xdg-dbus-proxy.
This seems like an obvious set of functionality to be grouped together
in service of the wider goal of making flatpak-utils smaller and more
manageable.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Each of these is only needed in one place, so move them there. This is
another step towards the utils module being the lowest-level.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The exports module doesn't actually need these, and this removes a
circular dependency: previously, exports both depended on and was
depended on by dir.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Following on from b8d8d80c61, add more environment variables used by
the Vulkan loader which expect paths to be provided.
These paths are typically referencing the host filesystem; if the user
is referencing paths only available in the sandbox, they can use --env
or overrides for them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Similar to how b8d8d80c61 inhibited passthrough of environment
variables pointing the Vulkan loader towards a specific ICD, do the same
for the EGL paths used by libglvnd to discover the GL driver to use, as
well as for NVIDIA's EGLStream shim.
These paths are typically referencing the host filesystem; if the user
is referencing paths only available in the sandbox, they can use --env
or overrides for them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
I don't think this env var makes much sense to pass into the sandbox
for similar reasons to LD_LIBRARY_PATH. Libraries from the host
just aren't relevant.
Users can still pass `--env=LD_PRELOAD=/foo` to use this functionality.
This particular bwrap invocation cannot cause a sandbox escape because
the command to run is hard-coded, but it's more clearly correct if we
pass "--" to every bwrap invocation.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This ensures that the command is not taken to be a bwrap option.
Resolves: CVE-2024-32462
Resolves: GHSA-phv6-cpc2-2fgj
Signed-off-by: Alexander Larsson <alexl@redhat.com>
[smcv: Fix DISABLE_SANDBOXED_TRIGGERS code path]
[smcv: Make flatpak_run_maybe_start_dbus_proxy() more obviously correct]
Signed-off-by: Simon McVittie <smcv@collabora.com>
As of LLVM/Clang 18 and LLD18 linker with the -export-dynamic option compilation ends with an error:
cc: error: unknown argument: '-export-dynamic'
For GCC and the default compiler this is not a problem. The problem occurs in Clang/LLD 18.
Fix tested on Mandriva via 39f1c03e91
This restores support for 'mixed' system locales where different locale
categories are configured with different languages. AccountsService
currently only includes the LC_MESSAGES language from the system locale.
Helps #5497
Otherwise, an out-of-bounds left shift can occur, as diagnosed by
UBSan here:
../../../../src/flatpak/common/flatpak-prune.c:387:14: runtime error: left shift of 253 by 24 places cannot be represented in type 'int'
Signed-off-by: Simon McVittie <smcv@collabora.com>
With older GLib, it's provided by libglnx, but with newer GLib, we need
to include the correct header.
Fixes: 7b1cd206 "Replace flatpak_close_fds_workaround() with g_fdwalk_set_cloexec()"
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is best effort. There is a 2s timeout and if something fails
everything continues on.
This is called from flatpak_dir_run_triggers because it gets called
whenever we might have changes to the exported service files.
Fixes#3342
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
<developer_name> has been deprecated in favor of <developer> with a
<name> child. We need to ensure that this developer name isn't parsed
as the application name.
Fixes: #5700
The hard-coding is not appropriate. According to libfuse 3.0.0 release
notes: "The fusermount and mount.fuse binaries have been renamed to
fusermount3 and mount.fuse3 to allow co-installation of libfuse 2.x
and 3.x". Some distributions seem to install a symlink, but this is
not upstream's default behavior.
In addition, fusermount might be provided from non-distro sources. So
a build-time option takes precedence over auto-detection logic.
Fixes#5104Fixes#5694
As discussed in #5695, I think we're reaching a point where removing
Autotools is preferable to fixing it.
1.14.x continues to use Autotools, so platforms whose Meson version is
too old can stay on that branch until it becomes unsupported. We have
a very conservative Meson dependency (Ubuntu 20.04).
Signed-off-by: Simon McVittie <smcv@collabora.com>
These symbols were soft-renamed in libmalcontent 0.5.0 (released in
February 2020). We can probably now safely depend on that, and use the
renamed versions.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
flatpak_close_fds_workaround() wasn't technically async-signal-safe,
because the requirement for sysconf() to be async-signal-safe was
removed in POSIX.1-2008.
It could also leave high fds open in some cases: in practice
sysconf(_SC_OPEN_MAX) returns the soft resource limit, but if our
resource limit has been reduced by an ancestor process, we could
conceivably still have fds open and inherited above that number.
We can fix this by using g_fdwalk_set_cloexec() with GLib >= 2.79.2,
or the backport in libglnx with older GLib. This uses close_range()
if possible, falling back to rummaging in /proc with async-signal-safe
syscalls.
Signed-off-by: Simon McVittie <smcv@collabora.com>
var_variant_dup_to_gvariant() returns a floating GVariant, and
g_variant_get_child_value() won't sink it, so we need to free it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_variant_get_child_value() returns a non-floating reference, so
g_variant_builder_add() will not sink it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is, strictly speaking, not allowed. On uncommon architectures like
CHERI, a pointer can be larger than a gsize.
This might also help to avoid AddressSanitizer losing track of
reachability, so that it won't think the array and its contents have
been leaked.
Signed-off-by: Simon McVittie <smcv@collabora.com>
1. For security context creation, only relies on WAYLAND_DISPLAY, do not
use WAYLAND_SOCKET since the file descriptor defined by WAYLAND_SOCKET
can be only consumed once.
2. Due to the incompatiblity between WAYLAND_SOCKET and the security
context, add a new permission --socket=inherit-wayland-socket
to limit the usage of WAYLAND_SOCKET to an opt-in feature. Only when
this flag is set, WAYLAND_SOCKET will be passed to the sandbox.
3. When WAYLAND_SOCKET is not inherited, set FD_CLOEXEC to avoid it to
be leaked the to sandbox.
Closes: #5614
As noticed on #5615, under normal circumstances, flatpak-run(1)
replaces itself with the bwrap process via execve(), and does not
close any fds that it might have inherited from its parent. This
allows for patterns like:
flatpak run com.example.App --in-fd=3 --out-fd=5 3<foo 5>bar
However, using execve() is annoying when trying to analyze code
coverage, because the coverage instrumentation does not get the
opportunity to write out its data during exit, so it is possible to
set FLATPAK_TEST_COVERAGE=1 to make flatpak run the app as a child
process and wait for it. This puts us on the code path normally used
for apps launched in the background by flatpak_installation_launch_full(),
which *don't* inherit arbitrary fds from their parent.
Detect this situation and use a different child setup function,
avoiding closing fds that we were meant to inherit.
Fixes: 88a928ea "run: Avoid execve() when measuring test coverage"
Signed-off-by: Simon McVittie <smcv@collabora.com>
In order to maintain a system over time update automatically removes any EOL runtimes that are unused.
This extends it to also remove any autopruned refs. In practice this means removing no longer used driver versions as the system is updated.
Closes#5261
Currently if the parental controls check can't connect to the system
bus, apps are not allowed to run. However, apps are also allowed to run
if the malcontent (or accounts-service) D-Bus services aren't available.
Since it's trivial to meet that requirement by starting a temporary
dbus-daemon and setting `DBUS_SYSTEM_BUS_ADDRESS` to use it, not being
able to access the system bus at all is no less secure.
This primarily affects flatpak running in a container where D-Bus is
generally not available.
Fixes: #5076
This means we can still test the old code path, even when a newer version
of AccountsService that will take the newer code path is available.
Signed-off-by: Simon McVittie <smcv@collabora.com>
