Otherwise fontconfig falls back to a shared ~/.fontconfig dir
which means caches are not per-app, and is not necessarily accessible.
(cherry picked from commit fef8743f26)
Closes: #1115
Approved by: alexlarsson
Icons are really only a bunch of pngs, and the icon theme specification
has been stable since forever and never broke ABI. So, exposing the
host fonts should be pretty safe, comparable to the fonts that we
already expose.
This ends up being kind of important since a lot of things pick up the
icon theme from the host. In particular, it means that libXcursor can pick up
the correct cursor icons for the current cursor theme.
(cherry picked from commit 1ee74fc5ea)
With the latest ostree, pull --mirror does not mirror the
summary for partial pulls, so system-wide installs fail. We
fix it by manually updating the summary.
Origin: backport, 0.9.6, commit:e987d92ad03981895a2a60db4f82420a12cd6cb7
This is solved in a much nicer way on master, using new ostree
APIs. However, here we take a brute-force approach of scanning
all staged files and ensuring we don't have any files or
directories with invalid modes before committing the transaction.
If any bad permissions were found we delete the entire staging
directory.
This goes into a big old topic about Unix homedir permissions; it's not uncommon
for general purpose OS vendors to have homedirs be 0755. In that case,
applications need to ensure confidentiality for data requiring it (classically
e.g. `~/.ssh`) by making the dirs `0700`.
While most of the data in the flatpak per-user dir probably isn't confidential
(debatably) we have a different issue; if container content includes suid or
world-writable files/dirs, then having that data accessible to other users
is obviously problematic.
We're going to fix flatpak/ostree to not create files with those modes
to begin with, but this simple fix closes off the attack route for
the per-user directory.
A different fix will be necessary for the system-wide repo.
See: https://github.com/flatpak/flatpak/pull/837
(cherry picked from commit daf36ba2af)
Looking at the git history, this code originally retried on
some cases for pull, then stopped doing so, then a later commit
added code after it, which made it incorrect.
Just do an early return again and drop the `res` variable.
(cherry picked from commit 4714f55ebd)
g_variant_get_type_string() is like g_dbus_message_get_signature(),
not like G_VALUE_HOLDS_STRING(). Use g_variant_is_of_type() to get
the equivalent of G_VALUE_HOLDS_STRING(). This was correct on master,
but went wrong during backporting to 0.8.x.
Signed-off-by: Simon McVittie <smcv@debian.org>
We previously required the directory to be writable to expose
it in the app-specific directory. However, the file was already
made visible in the regular location, and it was explicitly requested
by the app, so not allowing it to be there read-only makes no sense.
In particular, this allows KDE apps to use
--filesystem=xdg-config/kdeglobals:ro to allow apps to pick up global
configurations such as theme, etc, in a safe way.
(cherry picked from commit 1d9fe6fbf3)
This backports the minimal support for migrating a remote to
a new url/gpg-key from master (see commit 21778f1075
and 7a4c82529e).
The support is manual (you must run flatpak remote-modify --update-metadata) and
only supports the client-side consuming parts. You have to use the 0.9.x
series to update the server-side repository.
WAYLAND_DISPLAY can be other than "wayland-0" for various reasons, such
as using a custom Wayland display server or the session display server
using a custom display name.
Note that for xdg-desktop-portal to support showing portal windows, the
xdg-desktop-portal service MUST use the same WAYLAND_DISPLAY.
(cherry picked from commit a1ff20ca0e)
There is a race condition in how the portals detects the peer app-id.
If we manager to open /proc/$pid/root, and then openat(fd,
".flatpak-info"), but the process dies inbetween the two, then the
.flatpak-info read-only bind mount (and all other mounts in the
namespace except the root one) is unmounted, so we will find
and empty .flatpakinfo file.
We fix this race by storing the contents in a regular file, but
also as a readonly bind mount on top of it.
For typical dbus portals the pid is the dbus proxy though, and in
that case the app can't modify the file, so we make it just
a file there instead of file + bind-mount.
(cherry picked from commit e7ad74c398)
Instead of exporting any files we add a whilelist
of directories that get exported:
share/applications
share/icons
share/dbus-1/services
This avoids potentially installing some kind of file that the
host system reads and interprets in a risky way.
Applications and dbus services are safe because we rewrite them.
Icons are safe as long as the image loaders are, and if they are
not we have worse problems.
This is based on what we do in master (commit
e8369a69ef), but that also
allows mimetypes and gnome shell provider files. These were made safe
using by rewriting during exports, but that code is not backported.
Add X-Flatpak=$app to rewritten desktop files.
Desktop files have multiple consumers, and this
makes it easier for them to know what to do.
(cherry picked from commit 66e91f55e8
and e75cff6bb5)
If the app explicitly grants access to the host /tmp (for
instance telegram) then when this is being exposed as a symlink
in the sandbox we get an error because /tmp already exists
as a dir, which we create very early on.
It doesn't really make sense to keep /tmp as a symlink in
the sandbox anyway, so we just special case this and mount
the symlink target as /tmp.
(cherry picked from commit f28d318cc9)
If you run "flatpak update" then we will never update to
a commit that is older than the currently installed one. This
protects against a man-in-the-middle attack that would otherwise
let the attacker downgrade to a previously signed version that
may have some vulnerability.
(cherry picked from commit 3ff6d312de)
We never want the system-helper to downgrade. If you want to run
not-the-latest version you need to be "real root". However, the
check for this was broken, as it compared the new commit with the
new commit, which was always ok. Instead check the timestamp
on the new commit with the current one.
(cherry picked from commit 266b9cb6f0)
We should not terminate the extension search just because
an earlier directory succeeds. Even non-existant directories
succeed, and anyway we should continue searching even if it
wasn't empty, because multiple subdir extensions may match.
Fixes https://github.com/flatpak/flatpak/issues/654
(cherry picked from commit 82aad1ccb1)
By splitting the extra-data setup - where we set the number of
extra-data downloads and auxiliary information - and download -
where we actually fetch the extra-data - we can have more precise
progress reports.
(cherry picked from commit d73090cc96)
This means an extension point can include extensions of multiple
(specified) versions. This is useful for e.g. the GL extensions,
where we want a single extension for all the essentially unversioned
GL extensions (like the nvidia one) that is used by all the
runtimes.
(cherry picked from commit 640a02315b)
Otherwise, anytime we fail in ostree_repo_write_metadata() will cause
an invalid free to happen, and flatpak to crash.
(cherry picked from commit d0b5b51076)
At the moment, flatpak applications are only given FamilyLocal family
xauth cookies from the Xauthority file. This is so, the sandboxed
application doesn't inadvertently get access to displays on other
computers.
But FamilyLocal isn't the only xauth family that's local. FamilyWild
entries can be local as well.
Furthermore, FamilyWild entries are preferable to FamilyLocal entries
when found, because they don't break if the system hostname is changed.
This commit makes FamilyWild xauth entries get propagated in the same
way as their FamilyLocal counterparts.
(cherry picked from commit a82708cb10)
So far, the installation of external apps can only be cancelled
before flatpak starts downloading the extra data, as there's no
cancellable being passed to g_input_stream_read_async().
This fixes that problem, making it possible to cancel installs
from GNOME Software regardless of the installation stage.
(cherry picked from commit 86bf88d89f)
Otherwise, clients such as GNOME Software won't be able to report
any progress once the flatpak application has been downloaded and
we enter the stage to download the extra data.
(cherry picked from commit 2e1740297c)
Otherwise, all the progress reporting for the extra data being downloaded
won't work, as the main context used by OstreeAsyncProgress will not be
the same than the one from the nested main loop used to download this.
(cherry picked from commit ca952b0f21)
It turns out that it is impossible for to get ptrace capabilities
for child user namespaces in the current kernel if the user
namespace is created as root, which is what happens when bwrap
is setuid root (see https://github.com/flatpak/flatpak/issues/557
for details).
This is very problematic, as ptrace rights controls access to
/proc/$pid/root which is what we base the detection of peer
app id and rights on for portals.
For now, we disable user namespaces (except for the case of
unprivileged user namespaces, where it is necessary and works).
(cherry picked from commit 521e7e6a37)
If we have network access, then nvidia talks to the xserver
and for some reason it then also needs /dev/nvidia-modeset.
So, lets add that to the dri device list.
(cherry picked from commit 763a686d87)
This is supposed to list all the currently loaded "non-standard" gl drivers.
If FLATPAK_GL_DRIVERS is set, then that is used, otherwise it looks
for an nvidia driver and if so, uses that, and always adding "default"
at the end which is meant to resolve to a stable mesa fallback build, as
well as "host" which can be used if you have a host-side driver
as an unmaintained extension.
(cherry picked from commit d4d15c7211)
If directory is "foo" and the extension id ends with ".ext" and
subdirectory-suffix is "sub" then the extension point will
be "/usr/foo/ext/sub" rather than just "/usr/foo/ext".
This is very useful when the extension point naming scheme is
"reversed". For instance, this happens for the /usr/share/themes directory.
An extension point for a gtk3 theme would be in /usr/share/themes/$NAME/gtk-3.0,
which could be achived by using subdirectory-suffix=gtk-3.0.
(cherry picked from commit 5e1d456b8b)
If your extension points set this, then each extension will have
the corresponding subdirectory added to LD_LIBRARY_PATH.
We also support a priority property in the ExtensionOf group
in the extensions themselves to set the search order.
(cherry picked from commit a3da0b3da8)
