Previously we were relying on flatpak-utils-private.h having a circular
dependency on this, but I'm intending to remove that during future
refactoring.
Signed-off-by: Simon McVittie <smcv@collabora.com>
They are the same as `flatpak run --sandbox` with two exceptions:
* `FLATPAK_RUN_FLAG_MULTIARCH` might be required so we just add it
always
* `FLATPAK_RUN_FLAG_NO_PROC` is added to prevent sandbox escapes via
`/proc/self/exe`
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
This could be uninitialized if the app has --socket=fallback-x11 but
not --socket=wayland, although that's a combination that doesn't make
a great deal of sense. Regression introduced during recent refactoring.
Fixes: db7a8bb5 "common: Split up socket setup from flatpak-run into multiple files"
Signed-off-by: Simon McVittie <smcv@collabora.com>
Use the real GLib function if we can, and resync the backport with the
version in GLib 2.76.2: use a compatibility replacement for
G_NUMBER_PARSER_ERROR so that it can be textually identical to the
version in GLib, and revert Flatpak changes to the whitespace.
The only functional change is that if the function fails, we'll raise
G_NUMBER_PARSER_ERROR_INVALID if GLib is new enough.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Currently this is used unconditionally, even if GLib is new enough.
That will be changed in a subsequent commit; no functional change
intended in this one.
Signed-off-by: Simon McVittie <smcv@collabora.com>
- 0e7bf99e "Use "e" mode flag in fopen () calls for race-free setting of the close-on-exec flag"
- Add #ifndef G_OS_WIN32, which is irrelevant for Flatpak but keeps the
code textually equivalent to GLib's
Signed-off-by: Simon McVittie <smcv@collabora.com>
- 3384ed3f "Fixing signedness warnings in glib/gdatetime.c"
- faa1d63c "glib: Fix various compiler warnings when compiling with G_DISABLE_ASSERT"
- 4ddabfc6 "gdatetime: Avoid an assertion failure when parsing some ISO 8601 dates"
- b4eaac58 "gdatetime: Handle leap seconds in ISO8601 dates"
- f9d0135a "gdatetime: Port to use new g_time_zone_new_identifier() constructor"
(partially reverted here)
- c3805d74 "gdatetime: Disallow NAN as a number of seconds in a GDateTime"
- 5d7f4b8f "gdatetime: Remove floating point from seconds parsing code"
- d5580edf "Fix non-initialized variable in glib/gdatetime.c"
We can't backport GLib's implementations of these, because they make use
of GHashTable/GPtrArray internals. Instead, we have a reimplementation
of the same API, which accepts the cost of some redundant work as a
reasonable price to pay for backwards-compatibility.
Signed-off-by: Simon McVittie <smcv@collabora.com>
flatpak-utils.c is getting quite large, and is a mixture of code with
and without non-GLib dependencies, making it inconvenient to reuse in
other projects (like Steam's pressure-vessel) or link into Flatpak
services that don't need all of our dependencies (json-glib, appstream,
ostree). One obvious piece of low-hanging fruit for reducing the size
of this file is to move the GLib backports into their own
translation unit.
Sort them by GLib version, so that when we increase our GLib
dependency it's easy to delete the ones that are no longer applicable.
No functional changes intended in this commit.
Signed-off-by: Simon McVittie <smcv@collabora.com>
flatpak-run is large enough to be getting unwieldy, so separate it out
into various smaller modules.
A side benefit of these is that they'll be easier to reuse in other
projects, like Steam's pressure-vessel tool.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This mostly replaces `flatpak_transaction_add_rebase()`. It’s necessary
because the uninstall op for an eol-rebased app needs to be linked to
the install/update op for the rebased app, otherwise one op can proceed
after the other has failed (or they can be run in the wrong order) and
result in the old app being uninstalled but the new one not installed.
The following commit will port the internal flatpak `FlatpakTransaction`
subclasses to use it. Other consumers of `FlatpakTransaction` (such as
gnome-software) will have to be ported as well.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3991
This will be used in the next commit to simplify some new code.
Currently, this introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #3991
This feature (added in https://github.com/containers/bubblewrap/pull/488)
allows us to improve the guarantees of disallowing the sandbox to use
recursive user namespaces (which is a security risk) compared to the
existing limits that use seccomp.
[smcv: Move this to flatpak_run_setup_base_argv() so it will apply
equally in apply_extra_data() and `flatpak build`; make the compile-time
check for a setuid bwrap into a runtime check]
Co-authored-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
All g_autofree and g_autoptr variables should be initialized, either
with a value or NULL, and some gcc versions warn if they are not.
This particular instance was harmless, because we initialized regexp
to either NULL or a valid non-NULL value as the first statement of the
function, so there was no way to return before regexp was initialized;
but if we introduced an early-return such as a g_return_val_if_fail
before the current first statement, then that early return would have
caused uninitialized stack contents to be freed, likely resulting in a
crash.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The checksum here can leak if `flatpak_dir_remote_load_cached_summary()`
returns false at least once.
Spotted by asan while running gnome-software:
```
Direct leak of 2925 byte(s) in 45 object(s) allocated from:
#0 0x7f44774ba6af in __interceptor_malloc (/lib64/libasan.so.8+0xba6af)
#1 0x7f44764c941a in g_malloc ../../source/glib/glib/gmem.c:130
#2 0x7f445bc860e7 in ostree_checksum_from_bytes src/libostree/ostree-core.c:1599
#3 0x7f445bdbea82 in flatpak_dir_remote_fetch_indexed_summary /opt/gnome/source/flatpak/common/flatpak-dir.c:12563
#4 0x7f445bd9932e in flatpak_remote_state_ensure_subsummary /opt/gnome/source/flatpak/common/flatpak-dir.c:577
#5 0x7f445bdbfd42 in _flatpak_dir_get_remote_state /opt/gnome/source/flatpak/common/flatpak-dir.c:12872
#6 0x7f445bdc006c in flatpak_dir_get_remote_state_optional /opt/gnome/source/flatpak/common/flatpak-dir.c:12953
#7 0x7f445be07886 in flatpak_transaction_ensure_remote_state /opt/gnome/source/flatpak/common/flatpak-transaction.c:2057
#8 0x7f445be095c7 in flatpak_transaction_add_ref /opt/gnome/source/flatpak/common/flatpak-transaction.c:2732
#9 0x7f445be09c37 in flatpak_transaction_add_update /opt/gnome/source/flatpak/common/flatpak-transaction.c:2940
#10 0x7f445bdd202c in flatpak_installation_list_installed_refs_for_update /opt/gnome/source/flatpak/common/flatpak-installation.c:1103
#11 0x7f445bf07824 in gs_flatpak_add_updates ../../source/gnome-software/plugins/flatpak/gs-flatpak.c:2082
#12 0x7f445bf2e2b9 in gs_plugin_add_updates ../../source/gnome-software/plugins/flatpak/gs-plugin-flatpak.c:484
#13 0x7f44770533b2 in gs_plugin_loader_call_vfunc ../../source/gnome-software/lib/gs-plugin-loader.c:620
#14 0x7f447705430f in gs_plugin_loader_run_results ../../source/gnome-software/lib/gs-plugin-loader.c:748
#15 0x7f447706cb03 in gs_plugin_loader_process_thread_cb ../../source/gnome-software/lib/gs-plugin-loader.c:3110
#16 0x7f44769967ed in g_task_thread_pool_thread ../../source/glib/gio/gtask.c:1531
#17 0x7f447650e760 in g_thread_pool_thread_proxy ../../source/glib/glib/gthreadpool.c:350
#18 0x7f447650dd02 in g_thread_proxy ../../source/glib/glib/gthread.c:831
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The TIOCLINUX ioctl is only available on Linux virtual consoles such as
/dev/tty1. It has several Linux-specific functions, one of which is a
copy/paste operation which can be used for attacks similar to TIOCSTI.
This vulnerability does not affect typical graphical terminal emulators
such as xterm, gnome-terminal and Konsole, and Flatpak is primarily
designed to be run from a Wayland or X11 graphical environment, so this
is relatively unlikely to be a practical problem.
CVE-2023-28100, GHSA-7qpw-3vjv-xrqp
Resolves: https://github.com/flatpak/flatpak/security/advisories/GHSA-7qpw-3vjv-xrqp
Signed-off-by: Simon McVittie <smcv@debian.org>
There isn't much in the way of legit reasons for this, but it's a
potential security footgun when displaying the text.
CVE-2023-28101, GHSA-h43h-fwqx-mpp8
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
Co-authored-by: Simon McVittie <smcv@collabora.com>
This prevents someone from placing special characters in order to
manipulate the appearance of the permissions list.
CVE-2023-28101, GHSA-h43h-fwqx-mpp8
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
If `no_deploy` has been set to `TRUE` in a transaction, then the
intention is that no changes will be made to the installed flatpaks.
Currently that's not the case for explicitly or implicitly added
uninstall operations. That's particularly bad for eol-rebase flatpaks
since they old version will be automatically removed without the new
version being installed. To address this, prevent uninstall operations
from being added for no deploy transactions.
Closes: #5172
If the `GDK_BACKEND` environment variable is present and it's value does
not match the Wayland and X11 socket configuration, then a GTK app will
fail to run since it will only consider the display backend from the
environment variable.
This should probably be extended to cover other display environment
variables such as `QT_QPA_PLATFORM` for Qt and `SDL_VIDEODRIVER` for
SDL. However, I've only tested this with GTK applications.
It's unhelpful to say something like "Key file contains line “x” which is
not a key-value pair, group, or comment" without specifying which file
we are talking about.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Inspired by the slight mystery of
https://github.com/flatpak/flatpak/issues/5192, this commit adds more
debug output to the functions that analyze installations for unused
refs. Some of the output is g_debug() (enabled by -vv) and some is
g_info() (enabled by -v) since otherwise the output would be too
verbose. This should hopefully help debug problems, not only related to
the unused refs code but anything involving dependencies.
Exporting to an existing repo on a Samba filesystem failed with EACCES
when libglnx called renameat() to replace the old summary.idx file.
error: renameat: Permission denied
This occurred even when the user had appropriate permissions to the file
and its ancestor directories. The problem was that flatpak had mapped the
old file into memory for reading, and still held a reference to that mapping
when attempting to replace the underlying file. Apparently this works on some
filesystems, but not on cifs.
We therefore release the memory mapping before replacing the underlying file.
Fixes#5257
Co-authored-by: Patrick <tingping@tingping.se>
Previously, --filesystem=/run would prevent apps from starting by
breaking our ability to set up /run/flatpak and /run/host. Now it is
ignored, with a diagnostic message, resolving #5205 and #5207.
Similarly, --filesystem=/symlink-to-root (or --filesystem=host) would
have prevented apps from starting if a symlink like
`/symlink-to-root -> /` or `/symlink-to-root -> .` exists, and refusing
to export the target of that symlink avoids that failure mode,
resolving #1357.
Resolves: https://github.com/flatpak/flatpak/issues/1357
Resolves: https://github.com/flatpak/flatpak/issues/5205
Resolves: https://github.com/flatpak/flatpak/issues/5207
Signed-off-by: Simon McVittie <smcv@collabora.com>
If $HOME is below a reserved path (for example `/usr/home/thompson`
for Unix traditionalists) or otherwise cannot be shared, or is a
symbolic link to somewhere that cannot be shared, then we will end
up running the app with $HOME not existing. This is unexpected, so
we should make more noise about it.
There are two situations here, both of which get a warning: if we have
--filesystem=home or --filesystem=host then we are trying to share the
real $HOME with the application, and if we do not, then we are trying
to create a directory at the location of the real $HOME and replicate
the chain of symlinks (if any) leading from $HOME to that location.
Unlike the previous commit, this is not expected to happen during unit
testing, so we do not use a g_warning() for this.
Diagnoses: https://github.com/flatpak/flatpak/issues/5035
Signed-off-by: Simon McVittie <smcv@collabora.com>
If the user gives us a override or command-line argument that we cannot
obey, like --filesystem=/usr/share/whatever or
--filesystem=/run/flatpak/whatever, then it's confusing that we silently
ignore it. We should give them an opportunity to see that their override
was ineffective.
However, there are a few situations where we still want to keep quiet.
If there is a --filesystem argument for something that simply doesn't
exist, we don't diagnose the failure to share it: that avoids creating
unnecessary noise for apps that opportunistically share locations that
might or might not exist, like the way the Steam app on Flathub asks
for access to $XDG_RUNTIME_DIR/app/com.discordapp.Discord.
Similarly, if we have been asked for --filesystem=host, the root
directory is very likely to contain symlinks into a reserved path, like
/lib -> usr/lib. We don't need a user-visible warning for that.
We actually use the equivalent of g_message() rather than g_warning(),
to avoid this being fatal during unit testing (in particular when we
do a `flatpak info` on an app that has never been run, which will
be unable to share its `.var/app` subdirectory). `app/flatpak-main.c`
currently displays them as equivalent to each other anyway.
Signed-off-by: Simon McVittie <smcv@collabora.com>
