If an app had no deploy data, and `flatpak_dir_update()` was called with
`opt_subpaths == NULL`, then `arg_subpaths` passed to
`flatpak_dir_system_helper_call_deploy()` would be `NULL`, which causes
an assertion failure from an internal `g_variant_new()` call:
```
g_variant_new_strv: assertion 'length == 0 || strv != NULL' failed
```
Fix that by setting the `subpaths` to an empty array if nothing else is
specified.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This follows up from GHSA-4ppf-fxf6-vxg2 to fix missing functionality
that I noticed while resolving that vulnerability, but is not required
for fixing the vulnerability.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some consumers of environment variables distinguish between present
with an empty value and absent. For example, if an environment variable
represents a search path like VK_ICD_FILENAMES, unsetting it often
results in use of a default, but setting it to the empty string results
in not searching any locations, which is sometimes what is desired.
The shell syntax "${BAR-unset}" expands to the value of ${BAR} if it
is set to anything (even an empty string), or to "unset" if not.
We can use that in the unit test to check that BAR is set to the
empty string in this case.
This follows up from GHSA-4ppf-fxf6-vxg2 to fix an issue that I noticed
while resolving that vulnerability, but is not required for fixing the
vulnerability.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This avoids some of them being filtered out by a setuid bwrap. It also
means that if they came from an untrusted source, they cannot be used
to inject arbitrary code into a non-setuid bwrap via mechanisms like
LD_PRELOAD.
Because they get bundled into a memfd or temporary file, they do not
actually appear in argv, ensuring that they remain inaccessible to
processes running under a different uid (which is important if their
values are tokens or other secrets).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Part-of: https://github.com/flatpak/flatpak/security/advisories/GHSA-4ppf-fxf6-vxg2
On systems with no XDG_RUNTIME_DIR, PulseAudio falls back to creating
a temporary directory in /tmp, then creating a symlink in
legacy directory ~/.pulse or its more modern replacement ~/.config/pulse.
The symlink is named according to the machine ID, falling back to the
hostname.
Resolves: #4058
Might-resolve: #2169
Signed-off-by: Simon McVittie <smcv@collabora.com>
As with flatpak run --parent-expose-pids, this will only work if we have
a working, non-setuid bwrap. Systems where user namespace creation is
restricted and bwrap needs to be setuid (Debian 10, RHEL/CentOS 7,
Arch Linux linux-hardened kernel) will have degraded functionality.
This option is similar to --expose-pids, except that instead of making
the subsandbox use a nested pid namespace inside the parent's, it makes
the subsandbox share the parent's pid namespace as-is, so that process
IDs in the parent and the subsandbox are interchangeable. This will
be useful if the parent and the subsandbox communicate via protocols
that assume a global view of the process ID namespace, for example
passing process IDs across an AF_UNIX socket or in shared memory.
In particular, this will be useful for Steam's pressure-vessel container
tool: the IPC between the Steam client and the "game overlay" loaded into
Steam games uses process IDs, and becomes confused if they don't match up.
This weakens the security boundary between a subsandbox and the parent,
but that's OK in some cases, especially if the subsandbox is being used
as a way to get a different runtime /usr (flatpak-spawn --latest-version
or #4018) rather than as a security boundary.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If network access is allowed, then we should probably allow name
resolution too.
This should be enough to make nss-resolve work inside flatpak. However,
it cannot be tested with GNOME runtimes, because GNOME runtimes do not
contain systemd. It also cannot be tested with the Fedora 33 flatpak
runtime, because this runtime contains systemd 246, where nss-resolve
uses D-Bus rather than varlink to communicate with systemd-resolved. And
there is no rawhide runtime, and will be no Fedora 34 runtime until F34
is branched. So currently it's not possible to actually test this
without building a custom runtime, which I have not attempted to do. I
have built flatpak myself and verified the resolved socket is mounted
properly inside the sandbox, but it would be better to test if it
actually works with a runtime that contains systemd 247.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1912131
This brings us closer to matching what happens in libpulse.so.0.
This path is the default for a system-wide PulseAudio instance, which
is discouraged on non-embedded systems but is easy to check for.
In particular, SteamOS, an "appliance"-style gaming OS, uses this
socket.
Adapted from Steam's pressure-vessel container tool, which reuses
various Flatpak modules, including this function.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In addition to the old summary.idx.sig we now create an identical file
in `summaries/$DIGEST.idx.sig`, where the digest is of the summary
index itself. This means it will have a unique name and there will
never be issues where downloading the index and signature will race
during an update.
We keep the new and the previous digested sigs every update to avoid
removing the previous one while its in use.
As suggested by simon in https://github.com/flatpak/flatpak/issues/3983
and https://github.com/ostreedev/ostree/issues/2250
Currently if a deploy file was created (because a flatpak is installed)
using an old Flatpak version (such as 0.10.1 that's in Endless 3.3.16),
it will not include every metadata key, such as "eol" and "eolr". Those
keys were added before deploy version 1. Then when the deploy file is
upgraded to version 3, the metadata is only copied so eol/eolr are still
missing even though they exist in the commit metadata.
So this commit adds deploy version 4 which ensures all metadata keys in
the deploy file are present (when they are present in the source data).
All existing deploy files will be upgraded with this code.
This change is important because we use the end-of-life information to
decide whether an unused runtime should be uninstalled, so without this
change we are not freeing up disk space that we should be.
In elementary OS, we're building our images with some flatpaks pre-installed. To do this, we run noninteractive `flatpak install` commands in the chroot as part of the build scripts. We've bumped into some build failures recently after switching to a version of flatpak with malcontent support built in.
After some debugging, it turns out installations are failing the parental controls checks with errors like `Failed to install org.gnome.Epiphany: Could not connect: No such file or directory` message. I'm assuming this is a failure to connect to the system bus in this method (since there isn't one in the chroot).
Is it reasonable to assume that UID 0 should be allowed to install whatever they want regardless of parental controls? I believe this would fix our issue too.
When installing to an installation we need to find the runtime to use
for the apply-extra-data script from the installation we're targeting,
because that is the one that FlatpakTransaction guaranteed has the
required dependencies (although its possible they came from the
default dependency source too, i.e. the system repos).
In particular, we run into this issue if nothing is installed
anywhere, and then we install an extra-data app into a custom
directory. The transaction will download the runtime, and it
will not be anywhere else. Without this change flatpak only
looked for the dependency in the systam an regular user dirs
where it isn't.
It seems that all `FlatpakTransaction`s add the default dep sources, so
the internal transaction used to list installed refs for updates should
do the same.
This fixes a bug where
`flatpak_installation_list_installed_refs_for_update()` would return an
error saying “The application x requires the runtime y which was not
found” if the app was installed in the user repo, the runtime was
installed in the system repo, and no remote was configured (or one was
configured `xa.noenumerate=true`) in the user repo to provide the
runtime. If a remote was configured, the error wouldn’t be returned, but
the app would be spuriously listed for an update as its runtime couldn’t
be found.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is syntactic sugar added in GLib 2.67.0, which makes it more clearly
correct when we return TRUE after a GDBus error.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As /usr/local points to ../var/usrlocal on Silverblue,
/run/host/usr/local was previously a broken link inside the
sandbox. This patch checks if /var/usrlocal exists and bind-mounts it
to /run/host/var/usrlocal.
See bug #4010.
The old summary had a ostree.commit.timestamp in the per-ref metadata
dict. However, since this was not used anymore by flatpak I removed it.
However, it turns out that flathub has infra that depends on this,
so I'm adding it back.
We reuse the data in the old summary for unchanged refs when
rebuilding the summary, to avoid having to read all the commits. In
the new world the new format summaries are used for this, which means
we have to keep the timestamp in that too. However, to not be
unnecessary large its now using a shorter key name, as this is
duplicated for each ref in the summary.
Currently this error is happening on the eos3.9 dev branch of Endless
OS:
Nov 19 12:05:55 endless eos-updater-flatpak-installer[464]:
eos-updater-flatpak-installer: Couldn’t apply some flatpak update
actions for this boot: Error opening directory
'/root/.local/share/flatpak/app': Permission denied
The reason is that we have a check in flatpak_dir_list_unused_refs() to
check if the per-user installation exists and only try to list the refs
there if so, but the existence check falsely succeeds due to the systemd
sandboxing on eos-updater-flatpak-installer.service, and
flatpak_dir_list_refs() then fails in find_used_refs(). Specifically the
ProtectHome=yes systemd service option makes /root inaccessible, and due
to a bug in GLib[1] this makes g_file_query_exists() falsely return TRUE
for any paths under /root.
So, check for not found and permission denied errors rather than doing
an existence check, as we should be doing anyway to avoid a
time-of-check/time-of-use race, as explained in the
g_file_query_exists() documentation.
[1] https://gitlab.gnome.org/GNOME/glib/-/issues/1237
This is reported when we reported an error to the user via
::operation-error signal and the app told us to not continue.
If this happens in some weird case and we see the results its nice
to have access to the original error message.
There was a bug in the extension point matcher which made it
install `org.gnome.Totem.Videosite.YouTubeDl.Sources` (in addition to
`org.gnome.Totem.Videosite.YouTubeDl`) for the `org.gnome.Totem.Videosite`
extension.
We just need to make sure we only match the extension prefix if there
is a single element in the extension name following the extension
name (i.e. '.YouTubeDl', not '.YouTubeDl.Sources').
This fixes https://github.com/flatpak/flatpak/issues/3973
Building with Clang 11 shows a warning for the cast of the 'gpointer' to
'FlatpakFilesystemMode'.
This is due to '-Wpointer-to-int-cast' being now enabled by default.
common/flatpak-context.c:2144:13: warning: cast to smaller integer type
'FlatpakFilesystemMode' from 'gpointer' (aka 'void *')
[-Wvoid-pointer-to-enum-cast]
fs_mode = (FlatpakFilesystemMode) g_hash_table_lookup (context->filesystems, "host");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
In the main summaries we drop all the subset appstream branches.
In the subset summaries we use the relevant appstream branch and drop
the normal ones.
We also leave out the old compat branch completely from the subset
summaries because it will just be used for newer flatpaks that support
the new format.
Currently if an app has been renamed and you run "flatpak update" you
will be prompted to decide whether to install the new name of the app
(and uninstall the existing one). However, in such a situation
flatpak_installation_list_installed_refs_for_update() does not return
the app, and therefore gnome-software doesn't see any updates available
(except in the case where the installed commit is older than the commit
with the eol-rebase metadata).
So include end-of-life-rebased apps in the returned list. Patches to
make gnome-software update such apps properly are forthcoming.
I checked that the included unit test only passes with this patch to
libflatpak.
Philip Withnall