This is best effort. There is a 2s timeout and if something fails
everything continues on.
This is called from flatpak_dir_run_triggers because it gets called
whenever we might have changes to the exported service files.
Fixes#3342
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
The hard-coding is not appropriate. According to libfuse 3.0.0 release
notes: "The fusermount and mount.fuse binaries have been renamed to
fusermount3 and mount.fuse3 to allow co-installation of libfuse 2.x
and 3.x". Some distributions seem to install a symlink, but this is
not upstream's default behavior.
In addition, fusermount might be provided from non-distro sources. So
a build-time option takes precedence over auto-detection logic.
Fixes#5104Fixes#5694
These symbols were soft-renamed in libmalcontent 0.5.0 (released in
February 2020). We can probably now safely depend on that, and use the
renamed versions.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
flatpak_close_fds_workaround() wasn't technically async-signal-safe,
because the requirement for sysconf() to be async-signal-safe was
removed in POSIX.1-2008.
It could also leave high fds open in some cases: in practice
sysconf(_SC_OPEN_MAX) returns the soft resource limit, but if our
resource limit has been reduced by an ancestor process, we could
conceivably still have fds open and inherited above that number.
We can fix this by using g_fdwalk_set_cloexec() with GLib >= 2.79.2,
or the backport in libglnx with older GLib. This uses close_range()
if possible, falling back to rummaging in /proc with async-signal-safe
syscalls.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is, strictly speaking, not allowed. On uncommon architectures like
CHERI, a pointer can be larger than a gsize.
This might also help to avoid AddressSanitizer losing track of
reachability, so that it won't think the array and its contents have
been leaked.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In order to maintain a system over time update automatically removes any EOL runtimes that are unused.
This extends it to also remove any autopruned refs. In practice this means removing no longer used driver versions as the system is updated.
Closes#5261
This means we can still test the old code path, even when a newer version
of AccountsService that will take the newer code path is available.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This was new in GLib 2.60, but libglnx now provides a backport, so we
can use it unconditionally.
We still need a wrapper because g_strv_equal() is not NULL-safe, but
it's a very thin wrapper now.
Signed-off-by: Simon McVittie <smcv@collabora.com>
They are the same as `flatpak run --sandbox` with two exceptions:
* `FLATPAK_RUN_FLAG_MULTIARCH` might be required so we just add it
always
* `FLATPAK_RUN_FLAG_NO_PROC` is added to prevent sandbox escapes via
`/proc/self/exe`
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Use the real GLib function if we can, and resync the backport with the
version in GLib 2.76.2: use a compatibility replacement for
G_NUMBER_PARSER_ERROR so that it can be textually identical to the
version in GLib, and revert Flatpak changes to the whitespace.
The only functional change is that if the function fails, we'll raise
G_NUMBER_PARSER_ERROR_INVALID if GLib is new enough.
Signed-off-by: Simon McVittie <smcv@collabora.com>
All g_autofree and g_autoptr variables should be initialized, either
with a value or NULL, and some gcc versions warn if they are not.
This particular instance was harmless, because we initialized regexp
to either NULL or a valid non-NULL value as the first statement of the
function, so there was no way to return before regexp was initialized;
but if we introduced an early-return such as a g_return_val_if_fail
before the current first statement, then that early return would have
caused uninitialized stack contents to be freed, likely resulting in a
crash.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The checksum here can leak if `flatpak_dir_remote_load_cached_summary()`
returns false at least once.
Spotted by asan while running gnome-software:
```
Direct leak of 2925 byte(s) in 45 object(s) allocated from:
#0 0x7f44774ba6af in __interceptor_malloc (/lib64/libasan.so.8+0xba6af)
#1 0x7f44764c941a in g_malloc ../../source/glib/glib/gmem.c:130
#2 0x7f445bc860e7 in ostree_checksum_from_bytes src/libostree/ostree-core.c:1599
#3 0x7f445bdbea82 in flatpak_dir_remote_fetch_indexed_summary /opt/gnome/source/flatpak/common/flatpak-dir.c:12563
#4 0x7f445bd9932e in flatpak_remote_state_ensure_subsummary /opt/gnome/source/flatpak/common/flatpak-dir.c:577
#5 0x7f445bdbfd42 in _flatpak_dir_get_remote_state /opt/gnome/source/flatpak/common/flatpak-dir.c:12872
#6 0x7f445bdc006c in flatpak_dir_get_remote_state_optional /opt/gnome/source/flatpak/common/flatpak-dir.c:12953
#7 0x7f445be07886 in flatpak_transaction_ensure_remote_state /opt/gnome/source/flatpak/common/flatpak-transaction.c:2057
#8 0x7f445be095c7 in flatpak_transaction_add_ref /opt/gnome/source/flatpak/common/flatpak-transaction.c:2732
#9 0x7f445be09c37 in flatpak_transaction_add_update /opt/gnome/source/flatpak/common/flatpak-transaction.c:2940
#10 0x7f445bdd202c in flatpak_installation_list_installed_refs_for_update /opt/gnome/source/flatpak/common/flatpak-installation.c:1103
#11 0x7f445bf07824 in gs_flatpak_add_updates ../../source/gnome-software/plugins/flatpak/gs-flatpak.c:2082
#12 0x7f445bf2e2b9 in gs_plugin_add_updates ../../source/gnome-software/plugins/flatpak/gs-plugin-flatpak.c:484
#13 0x7f44770533b2 in gs_plugin_loader_call_vfunc ../../source/gnome-software/lib/gs-plugin-loader.c:620
#14 0x7f447705430f in gs_plugin_loader_run_results ../../source/gnome-software/lib/gs-plugin-loader.c:748
#15 0x7f447706cb03 in gs_plugin_loader_process_thread_cb ../../source/gnome-software/lib/gs-plugin-loader.c:3110
#16 0x7f44769967ed in g_task_thread_pool_thread ../../source/glib/gio/gtask.c:1531
#17 0x7f447650e760 in g_thread_pool_thread_proxy ../../source/glib/glib/gthreadpool.c:350
#18 0x7f447650dd02 in g_thread_proxy ../../source/glib/glib/gthread.c:831
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It's unhelpful to say something like "Key file contains line “x” which is
not a key-value pair, group, or comment" without specifying which file
we are talking about.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Inspired by the slight mystery of
https://github.com/flatpak/flatpak/issues/5192, this commit adds more
debug output to the functions that analyze installations for unused
refs. Some of the output is g_debug() (enabled by -vv) and some is
g_info() (enabled by -v) since otherwise the output would be too
verbose. This should hopefully help debug problems, not only related to
the unused refs code but anything involving dependencies.
This brings us one step closer to being able to stop using the flatpak2
log domain for messages that are exclusive to `flatpak -v -v`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_memdup() is subject to an integer overflow on 64-bit machines if the
object being copied is larger than UINT_MAX bytes. I suspect none of
these objects can actually be that large in practice, but it's easier
to replace all the calls than it is to assess whether we need to
replace them.
A backport in libglnx is used on systems where GLib is older than 2.68.x.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Following on from commit 85a83a06f9, add some code to clean up old
leaked deploy tmpdirs when we next try to deploy the same app
(successfully or not).
This should free up disk space leaked by failed deploys pre-85a83a06f95.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
These are the easy places to use the new `deploy_base_dfd` from to make
some more operations relative to an already-open dirfd in
`flatpak_dir_deploy()`.
This should introduce no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This already happens for installs due to the cleanup path in
`flatpak_dir_deploy_install()`, but it doesn’t happen for other calls to
`flatpak_dir_deploy()`. Notably, during updates of already installed
apps.
Specifically, this means that if an app update is cancelled due to being
blocked by a parental controls policy, the temp deploy dir for that app
(such as
`~/.local/share/flatpak/app/com.corp.App/x86_64/stable/.somehex-XXXXXX`)
will be leaked. It will never be automatically cleaned up, as it’s not
in `/var/tmp` either.
Fix that by using `glnx_mkdtempat()` to create a scoped temporary
directory.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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.
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
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.
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.
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
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>
