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>
This avoids a race condition in versions older than 2.60, while still
verifying that we can compile successfully with GLib 2.56.
Not having GLib 2.60 means we can't compile libmalcontent on Ubuntu 18.04,
so move the libmalcontent dependency to the main build job (on Ubuntu
22.04, which is new enough). This also means we don't have to compile
it from source every time.
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>
(flatpak documents:2965757): GLib-CRITICAL **: 11:27:35.128: g_variant_iter_next_value: must not be called again after NULL has already been returned.
This is due to the applications iterator being checked twice even though it is empty.
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
Based on a change contributed by Léo Stefanesco; but instead of
unconditionally using FUSE 3, leave a fallback code path for FUSE 2 for
older distros.
Co-authored-by: Léo Stefanesco <leo.lveb@gmail.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
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>
Save folks a few keystrokes. There is a command which already has a '-u'
option, document-export, but it doesn't support --user so there should
be no conflict. However '-s' is used by the info command among others,
so we can't use that for --system.
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.
Now that we're using the same display number in the sandbox as on the
host, we can forget about overwriting it with :99.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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>
The Desktop Entry spec says that Exec= is only required if
DBusActivatable= is not set to true, so don't emit a warning when Exec=
is missing but not required.
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)
The docs for g_spawn_sync() say:
"Note that you must set the G_SPAWN_STDOUT_TO_DEV_NULL and
G_SPAWN_STDERR_TO_DEV_NULL flags when passing NULL for standard_output
and standard_error."
So add in the stdout flag when calling flatpak-validate-icon in the
build-export command. Without this, there's output in the test logs
from when they're building the test app, due to
https://github.com/flatpak/flatpak/pull/4803
As with the previous commits, try not to split translatable sentences.
See the discussion here about whether the "Warning: "/"Error: " prefix
should be separable:
https://github.com/flatpak/flatpak/pull/4963#discussion_r908326539
Also, don't translate the "(internal error..." message since internal
errors shouldn't be translated to make debugging easier.
It doesn't make a lot of sense to prompt for confirmation when an in-use
extension is requested to be uninstalled, but not do so for an in-use
runtime, even if (or perhaps especially since) the latter causes the
transaction to fail later on.
Use a "Info: " prefix which matches the message printed in
print_eol_info_message(). Also make the message accurately use either
the word "runtime" or "extension" as appropriate.
Based on discussions on the issue tracker, it seems that users sometimes
remove runtime extensions without really understanding whether they're
in use. Add a confirmation prompt to address this.
Helps: #4549
flatpak_dir_list_app_refs_with_runtime_extension() only works when the
runtime extension it is passed and the apps it returns are both
installed. Sometimes a end-of-life message is printed for a runtime that
is not installed but is being installed by the current transaction, or a
runtime that is installed but one of the apps that needs it is being
installed by the current transaction. To cover these cases, check the
operations in the current transaction when building informational
messages about EOL runtimes.
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
