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)
When calculating the progress of a flatpak installation,
it considers the extra-data and OSTree pull as different
operations and that makes the progress to go back and
forth between 0% and 100%.
Consumers of this API, like GNOME Software, end up having
a bad experience reporting the progress of a Flatpak app
instalation.
Fix that by using a set of heuristics to improve the process,
splitting the operation in parts that can be tracked (or at
least estimated).
(cherry picked from commit d74956c23a)
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)
* Append flatpak data dirs if XDG_DATA_DIRS is already set
Otherwise it will be impossible to run flatpak apps from desktop menus.
This issue can happen if another app (e.g. snapd) wants to add custom
folders to XDG_DATA_DIRS through /etc/profile.d
If XDG_DATA_DIRS is empty or unset, define it as before.
Fixes#606
(cherry picked from commit a9acdc0532)
For a few commands the options aren't fully documented. This commit
makes the manpage documentation (almost) match the options shown
when you run "<command> --help" on the command line.
(cherry picked from commit 2d07f7d455)
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)
