Since we switched to libappstream we really have an implicit dependency
on this, as there are no versions of it building with glib earlier
than 2.46.
This isn't dropping a lot of old code, but at least it is more truthful
about our actual dependencies.
Of the 19 instances where g_mkdir_with_parents() is used, these are
the only ones where the return value is ignored. This triggers
Coverity.
It might not be strictly necessary to handle the errors, but doing so
can only help with debugging.
Of the 16 instances where g_file_delete() is used, these are the only
ones where the return value is ignored. This triggers Coverity.
It might not be strictly necessary to handle the errors, but doing so
can only help with debugging.
This makes it a lot easier to give guidance on using `flatpak run -d` or
`flatpak-coredumpctl`, because there's an easy way to install the
relevant refs.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
We support the "summary-arches" variable to limit which arches goes
into the compat summary file. However, its currently always adding in
the compat arches of whatever arches you list. This means we can't
e.g. keep compat summary support for aarch64, but not for armv7, which
is a problem as we're nearing the 10MB summary size limit of ostree
for old clients.
So, just keep the exact arches listed. If you want to keep compat
arches, you need to explicitly list them.
As with commit de9fe1cb "common: Work around new glib codegen
autogenerating g_autoptr support", this avoids colliding with newer
versions of gdbus-codegen generating their own autocleanups. This is
helpful when using Meson, in which the gdbus-codegen integration
generates more autocleanups by default.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As discussed in #4848, this disables fuzzy matching entirely if stdin or
stdout is not a tty, meaning that something like "flatpak install
firefox" would be treated as incorrect syntax, since this syntax is
intended for interactive CLI use. Even before this commit, "flatpak
install firefox" would error out if run without a tty, since we don't
automatically choose a matching app ID even if there is only one match.
However "flatpak install -y firefox" could work before, but won't any
more. People should be specifying the full app ID in any context other
than a tty.
This commit also introduces a new env var so the unit tests can continue
to check the fuzzy matching behavior, despite them being run without a
tty.
If we're using a system copy of xdg-dbus-proxy, it's not really correct
to include a header from our subproject (which we are otherwise not
going to be compiling), and Meson is stricter about this than Autotools.
Instead, duplicate the FlatpakPolicy enum, which is the only part we
actually need.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Recent Meson versions have warnings if you add the subprojects
directory as an include path, because the way Meson wants to consume
subprojects is by the subproject's build system producing a Meson
dependency object that encapsulates its include directory. Flatpak
doesn't have a Meson build system yet, but I'm working on that.
libglnx seems to be set up to have the libglnx directory be its include
path instead: for example, ostree (by the author of libglnx) already
uses "libglnx.h" or <libglnx.h> everywhere. Do the same here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Currently, when using the sideloading support for offline updates, there
are two types of directories that are interesting: an ostree repo
directory on a directory that was passed to `flatpak create-usb`. By
default the latter has a repo at the subpath ".ostree/repo", and if a
custom destination was specified with "--destination-repo", a symlink is
created pointing to it in ".ostree/repos.d".
Currently Flatpak supports either repos or create-usb dirs in the
`sideload-repos` directory in either the Flatpak installation or
`/run/flatpak` (see flatpak(1)), but only supports repo directories
being passed to "--sideload-repo" for the install and update commands.
This is pretty confusing and actually made me think the sideload support
was broken because I forgot about this limitation. So change things so
we can accept either type of directory specified either way: via option
or via the "sideload-repos" directories.
I've tested all of the following cases:
- pointing to a repo with --sideload-repo
- pointing to a create-usb dir with --sideload-repo
- linking to a repo in ~/.local/share/flatpak/sideload-repos
- linking to a create-usb dir in ~/.local/share/flatpak/sideload-repos
- pulling from a sideload repo when online as a performance improvement
The subpath is resolved relative to the root of the commit, so we can
use either an absolute or a relative path interchangeably. When using
libostree < 2021.6 with GLib >= 2.71, absolute paths cause an assertion
failure here; that was a libostree bug and was fixed in 2021.6, but we
can interoperate with more versions by sticking to relative paths, and
there's no real reason to prefer absolute.
Resolves: https://github.com/flatpak/flatpak/issues/4805
Co-authored-by: Corentin Noël <corentin.noel@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
All the details of the bug are in:
https://github.com/ostreedev/ostree/pull/2549https://github.com/flatpak/flatpak/issues/3479
This patch works around it by marking the commit we're about to pull
partial, so that if the .commit object exists in a staging directory
from a previous failed pull, it will not be erroneously considered a
complete commit, even by affected versions of libostree that don't have
the above patch. If for some reason the commit in the staging dir is
complete, libostree should harmlessly verify that and pull it in.
Usually the commit we are pulling does not already exist in the local
repo, but add a check anyway so we don't risk marking a complete commit
as partial, and so this works on the code path from
"flatpak install --reinstall ..."
Fixes#3479
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.
