If this environment variable is set on the host, it's going to mess up
authentication in the sandbox. For example, if the host has:
KRB5CCNAME=KCM:
then the sandboxed process will try to use the host KCM socket, which is
not available in the sandboxed environment, rather than the gssproxy
socket that we want it to use. We need to unset it to ensure that
whatever configuration we ship in the runtime gets used instead. We have
switched the GNOME runtime to use an empty krb5.conf and it works as
long as we don't break it with this environment variable meant for the
host.
We're using a directory rather than binding a socket directly for
increased robustness. In theory, if gssproxy crashes on the host, a new
socket that a new gssproxy process creates should be immediately visible
inside the sandbox. Nifty.
Previously, applications that wanted to use Kerberos authentication
would have to punch a sandbox hole for the host's KCM socket. In
contrast, this gssproxy socket is designed for use by sandboxed apps.
See also: https://github.com/gssapi/gssproxy/issues/45
`@filename@` expands to the relative or absolute path to the source
file, which varies between build systems and build directories.
`@basename@` expands to the basename of the file, which stays constant
across more build configurations.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_time_zone_new_offset() was new in GLib 2.58, but Ubuntu 18.04 'bionic'
only has GLib 2.56, and in theory we still claim to support versions
all the way back to GLib 2.46. If that function isn't available,
reimplement it in terms of the deprecated g_time_zone_new().
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some patches for Wine, as well as old 16-bit programs,
require this syscall to work.
As the only programs that need it are using --allow=multiarch,
this commit keeps it disabled when it isn't used,
as a security hardening measure.
For more information, see issue #4297.
To make indentation work with less effort. The modeline was copied from
libostree with minor modification and the .editorconfig from GLib.
The advantage of having both a modeline and an editorconfig is we can
work out of the box on more editor setups, and the modeline allows us to
specify the style with a lot more fine grained control.
There can happen a race condition between internal libcurl structure
content when two threads set the `data` structure for the callbacks
from two threads, which can cause access of already freed stack-allocated
`data`, resulting in a memory corruption.
Closes https://github.com/flatpak/flatpak/issues/3701
This helps to figure out what is going on if the expected paths are not
being exported.
The general design principle here is that I've used flatpak_debug2()
(which appears in `flatpak -v -v` but not `flatpak -v`) for situations
which occur under normal circumstances, and g_debug() (which appears
in `flatpak -v` or higher) for situations which are expected to be
uncommon.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We already allow normal apps to own MPRIS names but subsandboxes could not.
This allows them with the same dbus restrictions that they must be
prefixed by $app_id.Sandboxed.
This will be used by WebKitGTK.
Suppose the user's "real" X11 display on the host is Xorg or Xwayland
listening on :42, but they also have an Xvfb server listening on :99.
If we change the X11 display number to the arbitrary value :99, and
the Flatpak sandbox shares its network namespace with the host, then
clients inside the Flatpak sandbox will prefer to connect to the
abstract socket @/tmp/.X11-unix/X99 (which is Xvfb), rather than the
filesystem-backed socket /tmp/.X11-unix/X99 in the sandbox (which is
really /tmp/.X11-unix/X42 on the host, i.e. Xorg or Xwayland).
If they're relying on Xauthority (MIT-MAGIC-COOKIE-1) for access
control (as many display managers do), then this will fail, because
we gave the sandboxed app access to the cookies for Xorg/Xwayland
(rewriting their display number from 42 to 99 as we did so), but
Xvfb does not accept those cookies.
If we're relying on `xhost +"si:localuser:$(id -nu)"` for access control
(as gdm does), then the Flatpak app will successfully (!) connect to
whatever is on :99, for example Xvfb or Xephyr, which is rarely what
anyone wants either.
Resolves: https://github.com/flatpak/flatpak/issues/3357
Signed-off-by: Simon McVittie <smcv@collabora.com>
When Flatpak's P2P updates support was replaced with the "sideloading"
implementation in 1.7.1, a new server side repo config key
"deploy-sideload-collection-id" was added which gets set when you pass
"--deploy-sideload-collection-id" to "flatpak build-update-repo", and
has the effect of setting "xa.deploy-collection-id" in the repo metadata
that is pulled by clients, which itself causes a collection id to be set
on the remote for clients using Flatpak >= 1.7.1.
This commit adds an analogous key in flatpakref and flatpakrepo files,
so the collection id can be set when the remote is configured, rather
than later on when the repo metadata is pulled and acted upon. As before
with DeployCollectionID, it has no difference in function compared to
DeployCollectionID or CollectionID and the only difference is which
Flatpak versions are affected.
It would've been better if this were added in 1.7.1 when the sideload
support was added, but alas here we are.
(Also update the docs and unit tests)
Currently if a runtime extension, e.g.
org.freedesktop.Platform.html5-codecs//18.08 is used by a runtime
org.kde.Platform//5.12 which itself is used by one or more apps, when we
print a message to the user about html5-codecs being EOL, we don't find
any apps using it and don't print any. Fix this by including apps that
indirectly use a runtime extension in the "Applications using this
runtime:" list.
In a later commit we can re-use the helper function added here to add a
confirmation dialog if the user tries to remove a runtime extension
that's being used; currently we just let them remove it.
This is limited to only looking in the current flatpak installation, so
a per-user app using a system-wide runtime extension would not be found.
This is implemented using in-memory caches because otherwise it is
horribly slow; see
https://github.com/flatpak/flatpak/pull/4835#discussion_r876425289
Helps: #3531
This miniminzes the soup implementation by moving it out of the
highlevel multiple-retry entry points and simplifying the
lower level part to use only one shared helper.
This will also make it easier to replace the soup specific
parts.
This copies and simplifies some helpers from soup:
* Encoding url queries
* Parsing simple http header parameter lists
The goal is to use mostly GUri and a few extra helpers for the flatpak
internals, and then pass raw string uris to the http functions which
could then be backed by any kind of http implementation.
This allows:
* getting http status
* getting www-authenticate header
* Doing HEAD instead of get
This is needed by the OCI registry code for authentication
As discussed in https://github.com/flatpak/flatpak/pull/4582 we
want ot use GUri for soup3, and if we want to use libcurl we might
as well also use it to avoid complex ifdefs, as we're linking to it
already via glib.
This imports a subset of GUri for older versions of glib.
This will be useful in gnome-software's flatpak plugin, which currently
iterates over the operations a few times, and it will be useful
internally as well.
We don't support extensions of extensions, as evidenced by add_related()
only being called once in flatpak_transaction_real_run(), so there's no
need to read the metadata file of an extension in
flatpak_dir_find_local_related(), only to find that it doesn't have any
extensions of its own.
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>
