If the commit is available in the ostree-metadata and it matches what
the latest available commit in the p2p results then resolve it to that, so
we don't have to download the commit object.
This tries to resolve the p2p resolve operation from the info in
a ostree-metadata commit. This only works if the resolve ended up
on the same commit id as what was available in the ostree-metadata
which may not be correct if the two are not synchronized.
We extract the need-token key from the summary and if set we
calculate a token to use for the operation, which we then pass
to install/update.
For now the actual token just comes from the FLATPAK_TEST_TOKEN
environment var. The details of this will be fleshed out later.
Additionally, this does not support the p2p case, because there
we need the token in order to request the commit during the resolve.
This will also be added later.
This is in the same order as the xa.cache array and contains the id of
the commit that the cached data is about. This is not necessary in the
non-p2p summary metadata, because in that we always have a matching
ref -> commit array.
However, in the p2p case this information can be useful.
Historically the p2p resolve code always did a parallel call to find
all the available commits for the refs, and then it took the results
and pulled only the commits for all the refs so that it could resolve
against the exact commits that were available (which might not match
with whatever metadata we have in the local ostree-metadata copy.
This splits this into two phases, the first that uses the summary only,
and a second one that pulls the commit.
The reason for this is that we want to be able to do some stuff inbetween
these, such as resolving some refs via the ostree-metadata and maybe
requesting bearer tokens that we need for pulling the commit objects.
These are explicitly made short to save space, so lets have defines
for them to make sure we don't mistype them, especially as we
will be adding new keys.
These were added so that extra-data would work in #2954, however that
was a bit broad. We only need extension deps for extensions that:
1) Uses extra data (so we can run apply-extra)
2) Doesn't specify NoRuntime=true (because the apply-extra is static)
Fixes https://github.com/flatpak/flatpak/issues/3173
We were using i instead of handle to index the file descriptors, which
is likely to be the same (due to ordering) but not really
correct. Also rename the variables to make this code easier to read.
Also, add some bounds check on the handles wrt the fd list.
This means sandboxes with dbus access can use portals etc, but they can't
talk to the main app, or impersonate it, but you can still use dbus and
well-known names to talk to them if needed.
It does mean however that if you use this, different sandboxes can see each
other on the bus, so be careful.
This allows you to open up things (if the calling app has access) for
the sandboxed child.
Rather than duplicating all possible sandboxing technical details we
specify things at a higher level. We just assume you want the same
access as the caller (i.e. x11[-fallback] and/or wayland), as this is
easier to use for the caller and more flexible for us to later add new
technical details as needed.
Mount ~/.local/share/icons at /run/host/user-share/icons in
the sandbox, so runtimes can add /run/host/user-share to
their XDG_DATA_DIRS and get access to locally-installed
icon themes.
Mark installed apps to be updatable if an installed in missing
its runtime for some reasons. In pre-FlatpakTransaction world,
an app migration from runtime X to runtime Y would have rendered
an app unusable because runtime Y would not be installed
automatically by clients like gnome-software.
The goal here is that clients like gnome-software can show
those installed apps as updatable again, if such a situation
arises. The FlatpakTransaction API can automatically resolve one of
its ops to install the new runtime, provided we can mark the app
as updatable again at the first place.
While updating, if the related extension is missing on
the installation of an installed ref (could be an app or
runtime), FlatpakTransaction tends to "repair" the ref by
automatically downloading the related extension again and
restoring the overall functionality of the ref.
The related extension concerned that are the ones associated with
`should-download` to TRUE only.
Hence, teach the libflatpak API to do that same, so that clients
like gnome-software can mark those refs as updatable, if their
related extensions is missing.
FlatpakTransaction will automatically download the related ref
(.Locale ref in this case). In case of mentioning previous-ids
in the deploy file, the related ref(.Locale) should be also
be requiring an update.
Hence, flatpak_installation_list_installed_refs_for_update now
will return 2 refs (app and related .Locale extension) to be
updated, instead of 1.
The previous code checked whether the progress object had
"outstanding-fetches" set in order to decide whether it had been
initialized enough to show progress information. However, if the
callback saw a progress object on which flatpak_dir_setup_extra_data()
had not yet been called, then it would crash.
Therefore it seems that we should additionally be checking for the
presence of "outstanding-extra-data" which is set in
flatpak_dir_setup_extra_data().
It's likely that this wasn't previously a problem because the callback
would never get called due to the progress object's associated main
context not being iterated. It crashes now because that problem was
fixed in a previous commit.
Previously, in flatpak_dir_setup_extra_data(), n_extra_data (a gsize
which is 8 bytes wide on x86_64) was passed in a varargs list where an
unsigned int (4 bytes wide) was expected due to the "u" variant type
specifier.
This doesn't seem to have directly caused any crashes for me, but it's
undefined behaviour.
Therefore, this changes the affected keys "outstanding-extra-data" and
"total-extra-data" to be guint64 types instead of unsigned ints. The
gsize returned from g_variant_n_children() is cast to guint64 by virtue
of being assigned to a guint64-typed variable, but should not lose any
bits on supported platforms.
It's a common idiom in this codebase to push a temporary GMainContext as
the thread default context in order to run an async operation as if it
were sync. If we are not expecting progress callbacks this isn't a
problem, but it becomes a problem if we pass in an OstreeAsyncProgress
object that was created under a different GMainContext. The reason for
this is that OstreeAsyncProgress creates an idle source and attaches it
to the thread default context, so if we are iterating a temporary
context then the OstreeAsyncProgress's context never gets iterated, and
so no progress signals are fired.
To fix this, we introduce flatpak_progress_chain() and a RAII helper
FlatpakAsyncProgressChained which creates a new OstreeAsyncProgress
under the temporary GMainContext, but forwards all its state and updates
to the previous OstreeAsyncProgress's callbacks.
This is documented in a comment in the code as well.
All known instances of this problem in the existing code are fixed in
this commit.
This uses new API in libostree which is proposed in
ostreedev/ostree#1968. In anticipation of it being included in libostree
version 2019.6, the bug fix is predicated on that version being present.
If compiling against an older version, the old buggy behaviour will be
the fallback.
This problem was solved conceptually by Philip Withnall, I only wrote
the code.
There is no need to read the links, just look at the inode nr
which is the same info, and that also works on the bind-mounted
.userns thing where readlink fails.
Also, don't fail for non-existing namespaces.
Assuming unprivileged namespaces works we can now user the .userns
bindmount to access the intermediate bubblewrap user namespace.
This also drops the warning about root, and make sure we drop all caps
at the end.
Neither of these ever need a polkit agent, and run/build are somewhat
performance sensitive and we don't want to connect to dbus unnecessarily.
For enter this is critical though, as the dbus connection starts a thread
which is not compatible with the setns syscall.
There is a kernel issue which has been fixed in linux 4.9:
e98d413703
Which makes it impossible (on older kernels) to mount devpts unless
uid 0 is mapped in the user namespace. Bubblewrap works around this
by using two namespaces, the base one which sets up everything (and
thus owns all the other namespaces), and then at the end a child of that
that remaps uid 0 to the real uid.
Unfortunately, this makes it impossible to enter the bubblewrap user
namespace, because there are no references to the intermediate
user namespace we can use. To work around this we make a bind mount
of the intermediate namespace during setup using --ro-bind-try which
we can use for nsenter.
