Just as we already call flatpak_disable_fancy_output() in
flatpak_option_context_parse() in case verbose output is enabled via CLI
options, disable fancy output in case verbose output was enabled via the
G_MESSAGES_DEBUG env var. Without this change, the result of doing e.g.
$ G_MESSAGES_DEBUG=OSTree flatpak install ...
is pretty useless and ugly, when the output isn't being redirected to a
file, since the debug messages are overwritten when we redraw to show
progress updates.
This makes the output of "flatpak list" a bit ugly when G_MESSAGES_DEBUG
is set, but it seems like a small price to pay.
libappstream-glib is mostly unmaintained, and libappstream is more
actively developed (and up to date with the AppStream specification).
Port from libappstream-glib to libappstream. Handily, a lot of the APIs
are exactly the same. The main changes are:
* `AsApp` → `AsComponent`
* `AsStore` → `AsMetadata`
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(Mostly done by Philip, then Phaedrus finished this)
Older versions of bubblewrap would create a --file with mode 0666
(world-writeable), which is unexpected. Since bubblewrap 0.5.0, the
default is still 0666 for backwards-compatibility, but we can change it
with the new --perms argument. Switch to mode 0600 (private to user)
which is consistent with the mode of the --ro-bind-data version of
that file.
This is not a security issue: from outside the sandbox, this file can
only be accessed via /proc/$pid/root, which the kernel restricts to be
accessed by processes that could trace the sandboxed process (the same
uid or a privileged process), leading to a practical effect similar to
0600 permissions. Inside the sandbox, all processes have the same uid,
so 0600 and 0666 permissions are equivalent.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In older versions of bubblewrap, the --dir argument could only create
directories with mode 0755 (world-readable). The default mode is
still 0755, but since bubblewrap 0.5.0, we can change this to the mode
recommended by the basedirs spec (0700, private to user).
Since version 1.11.1, the --dir used here is normally redundant, because
each app-ID gets its own XDG_RUNTIME_DIR imported from the host
(it's actually $XDG_RUNTIME_DIR/.flatpak/$FLATPAK_ID/xdg-run on the host)
and those are correctly created with mode 0700. The one case where this
change makes a difference is that a sub-sandbox, created by
flatpak-spawn --sandbox or equivalent, does not share the common
XDG_RUNTIME_DIR and instead received an XDG_RUNTIME_DIR private to that
instance, with its permissions coming from this --dir argument.
This is not a security issue, because processes outside the sandbox can
only access this directory via /proc/$pid/root, which is only accessible
by processes that would be allowed to trace the sandboxed process
(either the same uid or a privileged process), resulting in behaviour
similar to the canonical 0700 mode. Inside the sandbox, all processes
have the same uid, so 0700, 0755 and even 0777 permissions would be
essentially equivalent.
However, some libraries that interact with XDG_RUNTIME_DIR, most notably
Qt, verify that its mode is 0700 as a hardening mechanism, and these
libraries did not work inside a Flatpak sandbox without being patched
to be more permissive.
Resolves: https://github.com/flatpak/flatpak/issues/3397
Signed-off-by: Simon McVittie <smcv@collabora.com>
libostree makes heavy use of fd-based I/O, which has the disadvantage
that it is rarely obvious what path an error message is referring to.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we are running a CLI command in the background, then EnsureRepo
might require authorization. Silently skip it if allow_empty was true,
as it is for commands that iterate through all repositories.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, if /var/lib/flatpak didn't exist then we would use the
system helper to create and populate it, but if it existed and was empty,
we could only populate it if we had privileges. This led to errors from
libostree:
Creating repo: mkdirat: Permission denied
The EnsureRepo method call is allowed by default for active local users,
so do this even if allow_empty is true: this will incorporate
/etc/flatpak/remotes.d into the repository, whether it is newly-created
or not. This makes a `flatpak search` work immediately, without having
to fetch metadata explicitly.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Due to previous bugs we were leaving a lot of temp files around
in the appstream deploy dirs, which could add up to using a lot of
space. So, lets find and delete these on updates.
This check only happens on a successful update to a new appstream,
which isn't that often, so the cost of this check is unlikely to be a
problem.
If during appstream deploy there is an error, the temporary files were
not deleted, resulting in leaked files in /var/lib/flatpak/appstream.
Over time these could add up to a significant size. In particular this
happes if several deploys happen in parallel, because then the final
move into place will fail with EEXIST.
This fixes the cleanup of both the temporary directory and the temporary
link on any error.
Fixes https://github.com/flatpak/flatpak/issues/4735
Put the configured server address string in PULSE_SERVER if it appears
to be remote. This should be enough for apps that already have network
access via --share=network.
If remote access to a PulseAudio server has been selected but the app
does not already have the --share=network permission, we don't want to
add --share=network automatically, because that would open up the app's
access to network resources, perhaps unexpectedly. However, users of
this non-default configuration can use `flatpak run --share=network` or
`flatpak override --share=network` to open up that access if they
consider it to be safe enough.
Resolves: https://github.com/flatpak/flatpak/issues/3908
Signed-off-by: Simon McVittie <smcv@collabora.com>
As with non-path-based AF_UNIX sockets, both of these are going to
require --share=network to be enabled, so print a warning if it isn't.
We don't automatically enable --share=network, because that elevates
the privileges of apps that would otherwise have entered a new network
namespace, but regular users of remote X11 can choose to enable it with
`flatpak run --share=network` or `flatpak override --share=network`.
Resolves: https://github.com/flatpak/flatpak/issues/397
Signed-off-by: Simon McVittie <smcv@collabora.com>
If the filesystem-backed Unix socket (G_UNIX_SOCKET_ADDRESS_PATH) does
not exist, X11 clients can also use a Linux abstract Unix socket
(G_UNIX_SOCKET_ADDRESS_ABSTRACT), or even a TCP socket.
Both of these are going to require --share=network to be enabled, so
print a warning if it isn't. We don't automatically enable
--share=network, because that elevates the privileges of apps that would
otherwise have entered a new network namespace, but users can make it
work with `flatpak run --share=network` or
`flatpak override --share=network`.
When falling back to an abstract Unix socket or to a TCP socket, we
can't remap the display number to the fixed :99.0 that we normally use,
so adjust write_xauth() to be able to avoid doing that.
Resolves: https://github.com/flatpak/flatpak/issues/4702
Signed-off-by: Simon McVittie <smcv@collabora.com>
In practice, au_len comes from one of the length fields in an Xauth
struct, which are all of type unsigned short, so it cannot really be
negative; but if we passed a negative argument here, the comparisons
would not behave as intended. Use the more correct size_t.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We're not going to call XauDisposeAuth on local_xa, so it's OK to put
a "borrowed" constant string here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
SHA1 hashes are considered weak these days. Some distributions have
static analysis tools to detect the use of such weak hashes, and they
get triggered by flatpak. While this particular use of SHA1 in flatpak
is likely not security sensitive, it's also easy to move to SHA256 to
avoid any debate.
Here, the SHA1 hash of a named remote's filter file is used to generate
the name of the directory where the refs from that remote are cached.
One can reasonably assume that the cache is frequently invalidated
because the list of refs on the remote changes all the time. Hence,
it's not big problem if it gets invalidated once more because of this
change.
Trying to run sandboxed GStreamer applications from within jhbuild, for
example, would make those applications fail to find their plugins.
$ LANG=C flatpak run org.gnome.Totem.Devel
** (totem:2): WARNING **: 19:32:06.406: Element 'gtkglsink' is missing, verify your installation
** (totem:2): WARNING **: 19:32:06.406: Element 'glsinkbin' is missing, verify your installation
Don't propagate those GStreamer environment variables to within the
sandbox to avoid that problem.
See https://gitlab.gnome.org/GNOME/totem/-/issues/504
Remove a redundant `PROP_0` member and add a type for the property IDs
so that the `switch` cases can be checked by `-Wswitch-enum`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This bundles up `{get,set}_no_interaction()` in a way which can be bound
or exposed to bindings.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This complements `flatpak_transaction_set_no_interaction()` and allows
calling code to see if a given transaction is interactive.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When generating flattened permissions (i.e. for --show-permissions or
for the /.flatpak-info file) we're currently flattening the permissions
i.e. don't show things that would only affect layering the permissions).
However, the code doesn't currently do this for the filesystem key, so
implement that. This means we only display the permissions that are
in effect, and don't display "negative" permissions like !host which
are not meaningful in this context.
This reintroduces the special case that existed in Flatpak 1.12.3, but
under a different name, so that it will be backwards-compatible. With
this change, flatpak-builder will be able to resolve CVE-2022-21682 by
using --filesystem=host:reset.
We want to implement this as a suffix rather than as a new keyword,
because unknown suffixes are ignored with a warning, rather than causing
a fatal error. This means that the new version of flatpak-builder will
be able to run against older versions of flatpak: it will still be
vulnerable to CVE-2022-21682 in that situation, but at least it will run.
Co-authored-by: Alexander Larsson <alexl@redhat.com>
This caused regressions for some previously-working use cases. For
example, some Flatpak users previously used a global
`flatpak override --nofilesystem=home` or
`flatpak override --nofilesystem=host`, but expected that individual apps
would still be able to have finer-grained filesystem access granted by the
app manifest, such as Zoom's `--filesystem=~/Documents/Zoom:create`. With
the changes in 1.12.3, this no longer has the desired result, because
`--nofilesystem=home` was special-cased to disallow inheriting the
finer-grained `--filesystem`.
This reverts commit 445bddeee6.
This reverts the initial solution to CVE-2022-21682, which we intend to
resolve differently, by introducing a new feature in Flatpak and making
use of it in a new flatpak-builder version.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Normally, we want to save a process and get better signal handling
by replacing the `flatpak run` process with bubblewrap.
However, when we're doing profiling or measuring coverage, we want to
exit cleanly so that profiling data can be recorded, which is done in
an atexit() hook. In this situation, bypass the execve() optimization;
instead, start bubblewrap in the background, immediately wait for it,
and propagate its exit status.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously --nofilesystem=host only removed specifically access to the
`host` permissions, and not necessarily other filesystems (like `home`
or `/some/path`). This isn't very useful to limit access because you
don't know what other filesystems the app may have access too.
We change this to mean that `--nofilesystem=host` removes *all* filesystem
access from the parent layer, and `--nofilesystem=home` removes all
file access to the homedir and paths inside it.
The available layers are, in order:
* app permissions
* overrides
* commandline args
This allows you to start from scratch with the filesystem permissions
in the overrides or the commandline. This is a small change in
behaviour, but not a lot of things use --nofilesystem, and the ones
that do probably expects this behaviour.
This was disables a long time ago because the fedora remotes didn't
contain metadata, but that has been added since then. Requiring fixes
a security concern where an app claims to require no permissions (by
having no metadata in commit) but then actually requires permissions
in the installed app.
If we fail to parse xa.metadata from the summary cache or the commit
xa.metadata we fail the resolve.
If xa.metadata is missing in the commit we fail the resolve (it is
always set in the summary cache, because summary update converts
missing xa.metadata to "", so we either get that, or cache miss which
leads to resolving from the commit.
This means that op->resolved_metadata is always set during install and
updates, which means we will show the app permissions. The transaction
will also always make sure that this data actually matches what gets
deployed.
Before this change an invalid metadata in the summary cache could lead
to a NULL resolved_metadata, which means we wouldn't print the app
permissions, yet we would still deploy some metadata file that could
have permissions. (NOTE: It would fail to deploy unless the
xa.metadata in the commit matched the metadata file, but in this
corner case we would't compare the summary and commit metadata, so
they may differ.)
In particular, if a null terminator is placed inside the metadata file,
Flatpak will only compare the text *before* it to the value of
xa.metadata, but the full file will be parsed when permissions are set
at runtime. This means that any app can include a null terminator in its
permissions metadata, and Flatpak will only show the user the
permissions *preceding* the terminator during install, but the
permissions *after* the terminator are applied at runtime.
Fixes GHSA-qpjc-vq3c-572j / CVE-2021-43860
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
Previously, the code would rescan the list of refs many, many times.
Now, it only scans once per flatpak_dir_find_local_related_for_metadata
invocation, and it also only parses each refspec once. On my local
system with a large number of refs (>200) installed, this reduces the
time for a `flatpak remove org.freedesktop.Platform//21.08` to start
from ~7s to ~2s.
This does result in dropping an optimization where ostree_repo_list_refs
is already given the ref kind, but IME the overall speed gains are still
worthwhile.
Fixes#4191.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
The history command seems to have been broken since it was changed to
use FlatpakDecomposed, since that type only works for app or runtime
refs, resulting in errors such as:
$ flatpak history
error: appstream2/x86_64 is not application or runtime
Fix this by making the logic a bit smarter, and don't let any one
invalid ref entry prevent the whole command from working.
Fixes#4332
This is another case where commit 4beaa990c seems to have mistakenly
turned an error code path into one where the deploy appears successful
to the caller of flatpak_dir_deploy() but the commit doesn't actually
get deployed.
If an app was created without a files/ directory, which shouldn't happen
with flatpak-builder but could happen if the commit is crafted manually,
currently the install operation exits successfully but the app is not
actually installed. Instead, error out, as we were doing before commit
4beaa990c2.
Have heard of people running Flatpak commands with both sudo and --user,
and not expecting it work on the root user's installation. Let's just
not allow it since it's not something people ever do intentionally.
Currently we verify the checksum of indexed summary files (which have
.sub file names) before writing them to the on-disk cache, so in theory
as long as the disk I/O is successful the data integrity should be
intact when we use it via the flatpak-variant-impl-private.h helpers
generated by variant-schema-compiler. However in practice people
sometimes hit assertion failures which are what you would expect to see
if the data is corrupt, since GVariant stores some metadata such as the
"offset size" toward the end of the data, and if we read this from
serialized user data instead it will obviously be incorrect. In one case
I was able to acquire the flathub.idx, flathub.idx.sig, and
flathub-x86_64-fad08cfb10713e749f02a0e894b5d577b7e9c4931fdf9d2fdc50364c002bc925.sub
files which reproduce one of the assertion failures, and the sub file
appears to be incomplete, like the writing of it was interrupted.
We use g_file_replace_contents() when saving these to the disk, and when
not replacing an existing file that function writes directly to the
final filename, so if interrupted it would be expected to leave an
incomplete file.
This commit changes the summary file handling so that we verify the
checksum of any indexed subsummary again after reading it from disk. If
it doesn't match we delete the on-disk cache and try fetching from the
network.
Fixes#4127
