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.
For historical reasons g_qsort_with_data() "only" works with up to 2**31
items, so it won't necessarily work for pathologically large arrays
and therefore is deprecated.
One advantage of g_qsort_with_data() and its replacement g_sort_array()
is that GLib guarantees that they are a stable sort (will not permute
items that already compare equal), which is not a guarantee for glibc's
qsort() and qsort_r(). However, I don't think it's actually relevant
whether we are doing a stable sort in any of these places: most of the
time we are sorting an array of unique items (often the keys of a hash
table, which are necessarily unique), therefore the compare function
will not compare equal in any case.
Another advantage of the GLib functions is that they are portable,
unlike qsort_r(). However, Flatpak is Linux-only, so we can freely use
useful functions like qsort_r().
Signed-off-by: Simon McVittie <smcv@collabora.com>
When iterating more than one group, the variable got clobbered.
Narrowing their scope helps.
This was triggered installing an Inkscape test build
Signed-off-by: Hubert Figuière <hub@figuiere.net>
KDE krunner supports DBus plugins that allow search completion
comparable to the already supported gnome-shell searchprovider.
Exporting the contents of the runner directory enables us to enable
search results from within flatpack applications.
We now resolve the zoneinfo and always make it available at
/usr/share/zoneinfo in the sandbox so we unset TZDIR to get flatpak apps
looking at the right directory.
We seem to have no interest in the specific error, as we are using it
locally just to "return". So there's no point in having the error in
the first place. In consequence, the error is only used in the loop
and can be declared locally to it.
This is more compliant with FHS specification. Most notably, /etc
is not appropriate to hold distro configuration, which is a common
use for the remotes.d feature. It is better practice to put things
under /usr/share, and let the system administrator modify /etc to
their will, of course giving them priority.
Update documentation to reflect this change.
In the process, move to use g_build_filename
Because flatpak_get_real_xdg_runtime_dir() return an allocated string
we have to return strduped.
Closeflatpak/flatpak#5920
Signed-off-by: Hubert Figuière <hub@figuiere.net>
This adds a new `usb` device in the list to grant access to the whole
USB bus. This is narrower than `all` and should be enough for
anything accessing the USB directly (i.e. using libusb or equivalent).
This doesn't grant access to synthesized devices, i.e those exposed
in `/dev` but using USB, including but not limited to USB serial, webcams,
hidraw, hid, sound.
Close#4405
Signed-off-by: Hubert Figuière <hub@figuiere.net>
This option allows the application (or subsandbox) to own the specified
name on the a11y bus. This will be useful for WebKit, that has a strict
security need that the Web processes cannot talk or see each other.
An alternative approach would be to make xdg-dbus-proxy permissions
modifiable at runtime, but that seems a lot riskier than this. Owning
a well known name based on the app id has proven to be a robust and
secure approach after all.
Every time we load something into the context, debug-log what it was.
Again, the more involved parts of this are skipped if debug logging is
disabled.
This will help to diagnose what is going on if the app metadata or the
command-line options are setting sandboxing parameters that break an app.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The more involved parts of this are skipped if debug logging is disabled.
This will help to diagnose what is going on when users have added
overrides that make their app not work as intended.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This can be used to disable code paths that assemble relatively
"expensive" debug information when debugging is not enabled.
It's activated by `flatpak -v -v`.
With a sufficiently modern GLib version, it also activates for
`G_MESSAGES_DEBUG=all` or `G_MESSAGES_DEBUG=flatpak`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
GLib has optimizations for hash tables that are sets (conventionally
represented as key == value), and the APIs to work with such hash tables
are also slightly nicer, so use them instead of putting an arbitrary
constant string in the value.
Signed-off-by: Simon McVittie <smcv@collabora.com>
For historical reasons C string literals are officially of type `char *`,
but if we build with -Wwrite-strings, they are `const char *` as they
should be.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Instead of passing a /proc/self/fd bind mount we use --bind-fd, which
has two advantages:
* bwrap closes the fd when used, so it doesn't leak into the started app
* bwrap ensures that what was mounted was the passed in fd (same dev/ino),
as there is a small (required) gap between symlink resolve and mount
where the target path could be replaced.
Please note that this change requires an updated version of bubblewrap.
Resolves: CVE-2024-42472, GHSA-7hgv-f2j8-xw87
[smcv: Make whitespace consistent]
Co-authored-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
These directories are in a location under application control, so we
can't trust them to not be a symlink outside of the files accessibe to
the application.
Continue to treat --persist=/foo as --persist=foo for backwards compat,
since this is how it (accidentally) worked before, but print a warning.
Don't allow ".." elements in persist paths: these would not be useful
anyway, and are unlikely to be in use, however they could potentially
be used to confuse the persist path handling.
This partially addresses CVE-2024-42472. If only one instance of the
malicious or compromised app is run at a time, the vulnerability
is avoided. If two instances can run concurrently, there is a
time-of-check/time-of-use issue remaining, which can only be resolved
with changes to bubblewrap; this will be resolved in a separate commit,
because the bubblewrap dependency might be more difficult to provide in
LTS distributions.
Helps: CVE-2024-42472, GHSA-7hgv-f2j8-xw87
[smcv: Make whitespace consistent]
[smcv: Use g_warning() if unable to create --persist paths]
[smcv: Use stat() to detect symlinks and warn about them]
Co-authored-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
parse_ref_file() cleared all its out params to NULL, with the exception
of collection_id_out. Make sure to clear this one as well to avoid
surprises in the future.
Fixes commit ae7d96037 that added collection ID support to flatpakref.
