These environment variables inform the Vulkan loader on where to find driver files.
Since they typically point to locations on the host filesystem, any application that
attempts to load Vulkan within the flatpak sandbox would break with these set.
(cherry picked from commit b8d8d80c61)
There was already a timeout set using `CURLOPT_CONNECTTIMEOUT`, but that
only affects the initial connection. Once a HTTP connection is
established, the timeout is ineffective.
That means that once a HTTP connection is established, there is no bound
on the length of time a download can take. Sometimes, downloads drop to
very low speeds (for Networking Reasons) and we need a way to give up on
a download if that happens.
So, set a low speed limit of 10KB/s for 60s. If a curl download goes
more slowly than this, it will be considered timed out, and the
`CURLE_OPERATION_TIMEDOUT` code path will be taken.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: https://github.com/flatpak/flatpak/issues/5519
(cherry picked from commit d6b10c26ef)
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>
(cherry picked from commit 43085c0e2a)
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>
(cherry picked from commit ce4bb3d153)
`ostree_raw_file_to_content_stream` will try to read it, causing a
critical warning with GLib 2.76 causing tests to fail.
(cherry picked from commit c9cbdf5179)
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
(cherry picked from commit fba3a7d35e)
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>
(cherry picked from commit 3ede5382fa)
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.
(cherry picked from commit cc122e2972)
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>
(cherry picked from commit f325564c9a)
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>
(cherry picked from commit b85d30365e)
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>
(cherry picked from commit dc7b1e873b)
This variable contains paths to load GIO modules from. For the most
part, they refer to paths outside of the sandbox or if they happen
to be in the sandbox, would contain modules that are incompatible with
the sandbox runtime (ie. different libc).
While I've not found programs that would crash outright, it may cause
unexpected behaviors (eg. Apostrophe not being able to render math in
preview panel).
This variable is set by NixOS for its dependency boxing.
(cherry picked from commit df0b9d98b5)
This variable is typically used to configure the use of a custom
set of XKB definitions. In those cases, it's mostly meant for the
X11 server or Wayland compositor. NixOS is known to employ this
variable for their custom XKB layout implementation.
When the path it points to is unreachable (due to the sandbox),
most GTK+/Qt applications will crash on Wayland.
Unsetting this does not seem to negatively impact the use of custom
XKB layouts with Flatpak applications.
(cherry picked from commit 751ff11d3a)
If this environment variable is set on the host, it's going to mess up
authentication in the sandbox. For example, if the host has:
KRB5CCNAME=KCM:
then the sandboxed process will try to use the host KCM socket, which is
not available in the sandboxed environment, rather than the gssproxy
socket that we want it to use. We need to unset it to ensure that
whatever configuration we ship in the runtime gets used instead. We have
switched the GNOME runtime to use an empty krb5.conf and it works as
long as we don't break it with this environment variable meant for the
host.
(cherry picked from commit 1c32317841)
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>
(cherry picked from commit 01910ad12f)
This should make it a bit clearer when `rm -rf` is being used in the
debug logs.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry picked from commit 6c7eb34dd6)
When filesystem=host access is provided, some root folders are hidden, including /boot.
The bootloader specification now recommends mounting the system EFI filesystem in /efi
(currently visible) instead of /boot/efi (currently hidden). This hides /efi for the same
reasons /boot is already hidden.
(cherry picked from commit 397c97de9f)
This supplements clearing TMPDIR env variable which is only one among variables used for storing temporary files. Any of those leaking from host may confuse flatpak apps which try to save temporary files under non-existing directory in sandbox.
See https://github.com/flathub/com.logseq.Logseq/issues/29 for real world example.
(cherry picked from commit d8695f3071)
This already happens for installs due to the cleanup path in
`flatpak_dir_deploy_install()`, but it doesn’t happen for other calls to
`flatpak_dir_deploy()`. Notably, during updates of already installed
apps.
Specifically, this means that if an app update is cancelled due to being
blocked by a parental controls policy, the temp deploy dir for that app
(such as
`~/.local/share/flatpak/app/com.corp.App/x86_64/stable/.somehex-XXXXXX`)
will be leaked. It will never be automatically cleaned up, as it’s not
in `/var/tmp` either.
Fix that by using `glnx_mkdtempat()` to create a scoped temporary
directory.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry picked from commit ce1829a703)
`@filename@` expands to the relative or absolute path to the source
file, which varies between build systems and build directories.
`@basename@` expands to the basename of the file, which stays constant
across more build configurations.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3a93ef4842)
g_time_zone_new_offset() was new in GLib 2.58, but Ubuntu 18.04 'bionic'
only has GLib 2.56, and in theory we still claim to support versions
all the way back to GLib 2.46. If that function isn't available,
reimplement it in terms of the deprecated g_time_zone_new().
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3591ba08f6)
To make indentation work with less effort. The modeline was copied from
libostree with minor modification and the .editorconfig from GLib.
The advantage of having both a modeline and an editorconfig is we can
work out of the box on more editor setups, and the modeline allows us to
specify the style with a lot more fine grained control.
There can happen a race condition between internal libcurl structure
content when two threads set the `data` structure for the callbacks
from two threads, which can cause access of already freed stack-allocated
`data`, resulting in a memory corruption.
Closes https://github.com/flatpak/flatpak/issues/3701
This helps to figure out what is going on if the expected paths are not
being exported.
The general design principle here is that I've used flatpak_debug2()
(which appears in `flatpak -v -v` but not `flatpak -v`) for situations
which occur under normal circumstances, and g_debug() (which appears
in `flatpak -v` or higher) for situations which are expected to be
uncommon.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We already allow normal apps to own MPRIS names but subsandboxes could not.
This allows them with the same dbus restrictions that they must be
prefixed by $app_id.Sandboxed.
This will be used by WebKitGTK.
Suppose the user's "real" X11 display on the host is Xorg or Xwayland
listening on :42, but they also have an Xvfb server listening on :99.
If we change the X11 display number to the arbitrary value :99, and
the Flatpak sandbox shares its network namespace with the host, then
clients inside the Flatpak sandbox will prefer to connect to the
abstract socket @/tmp/.X11-unix/X99 (which is Xvfb), rather than the
filesystem-backed socket /tmp/.X11-unix/X99 in the sandbox (which is
really /tmp/.X11-unix/X42 on the host, i.e. Xorg or Xwayland).
If they're relying on Xauthority (MIT-MAGIC-COOKIE-1) for access
control (as many display managers do), then this will fail, because
we gave the sandboxed app access to the cookies for Xorg/Xwayland
(rewriting their display number from 42 to 99 as we did so), but
Xvfb does not accept those cookies.
If we're relying on `xhost +"si:localuser:$(id -nu)"` for access control
(as gdm does), then the Flatpak app will successfully (!) connect to
whatever is on :99, for example Xvfb or Xephyr, which is rarely what
anyone wants either.
Resolves: https://github.com/flatpak/flatpak/issues/3357
Signed-off-by: Simon McVittie <smcv@collabora.com>
When Flatpak's P2P updates support was replaced with the "sideloading"
implementation in 1.7.1, a new server side repo config key
"deploy-sideload-collection-id" was added which gets set when you pass
"--deploy-sideload-collection-id" to "flatpak build-update-repo", and
has the effect of setting "xa.deploy-collection-id" in the repo metadata
that is pulled by clients, which itself causes a collection id to be set
on the remote for clients using Flatpak >= 1.7.1.
This commit adds an analogous key in flatpakref and flatpakrepo files,
so the collection id can be set when the remote is configured, rather
than later on when the repo metadata is pulled and acted upon. As before
with DeployCollectionID, it has no difference in function compared to
DeployCollectionID or CollectionID and the only difference is which
Flatpak versions are affected.
It would've been better if this were added in 1.7.1 when the sideload
support was added, but alas here we are.
(Also update the docs and unit tests)
Currently if a runtime extension, e.g.
org.freedesktop.Platform.html5-codecs//18.08 is used by a runtime
org.kde.Platform//5.12 which itself is used by one or more apps, when we
print a message to the user about html5-codecs being EOL, we don't find
any apps using it and don't print any. Fix this by including apps that
indirectly use a runtime extension in the "Applications using this
runtime:" list.
In a later commit we can re-use the helper function added here to add a
confirmation dialog if the user tries to remove a runtime extension
that's being used; currently we just let them remove it.
This is limited to only looking in the current flatpak installation, so
a per-user app using a system-wide runtime extension would not be found.
This is implemented using in-memory caches because otherwise it is
horribly slow; see
https://github.com/flatpak/flatpak/pull/4835#discussion_r876425289
Helps: #3531
This miniminzes the soup implementation by moving it out of the
highlevel multiple-retry entry points and simplifying the
lower level part to use only one shared helper.
This will also make it easier to replace the soup specific
parts.
