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)
For instance, org.my.App.* will now match org.my.App.foo.bar, and even
org.my.App, where it would previously only match org.my.App.foo.
This makes a lot of sense, because it allows you to structure the
subset of the dbus namespace you're granted how you please, and
there is no real security problem with this.
It also matches how arg0namespace works in dbus matches and how the
proposed dbus-implemented filterin works in:
https://bugs.freedesktop.org/show_bug.cgi?id=101902
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
libostree attempts to strip the setuid and setgid bits from file
permissions in user-mode checkouts, which, if successful, would make
Flatpak's check for setuid ineffective and unnecessary. In versions
older than 2017.7 this was not consistently applied, making commits
2c8e241 and 02a299f necessary to defeat CVE-2017-9780 (see #845).
libostree 2017.7 removes setuid and setgid bits more thoroughly
as a result of fixing https://github.com/ostreedev/ostree/issues/633
in PR https://github.com/ostreedev/ostree/pull/903, which means that
this test fails when linking flatpak 0.8.x to libostree 2017.7.
Signed-off-by: Simon McVittie <smcv@debian.org>
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)
Sometimes we get an EAGAIN error in the due to the socket being
nonblocking. In the setup phase we just allocated the new buffer
and this causes a leak. Free it in this case.
(cherry picked from commit 6a63a905bf)
The header returned from parse_header contains references
to the buffer it was used to parse from, and in some
cases we dereference these headers after freeing the buffer.
For instance this happens when we're filtering a message, and
then we later look at the destination to figure out what
kind of error to send back.
I couldn't find any cases where this would let the client
do anything other than return a different error value, but
this is still possibly a security issue.
(cherry picked from commit 18a45712cc)
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)
This is required for e.g. G_DECLARE_FINAL_TYPE, and most current
distros have this now.
This fixes https://github.com/flatpak/flatpak/issues/622
For distributions that want to build against older glib, see
the issue above, it has patches to make that work.
(cherry picked from commit dcccb3c807)
