The client-side proposed for flatpak-spawn uses --app-path, but the
actual implementation on D-Bus uses file descriptor passing and an
option named app-fd, so the documentation of the D-Bus interface should
be written in terms of app-fd.
Fixes: 3ebf371f "run: Allow caller to replace /app and/or /usr"
Signed-off-by: Simon McVittie <smcv@collabora.com>
The pressure-vessel container tool in Steam will want to use this, to
replace /usr with a Steam Runtime container supplied by the Steam CDN,
instead of using the same Flatpak runtime that is used to run the Steam
client and non-containerized games.
If a custom /usr is used, the "official" Flatpak runtime is still the
one reflected in the metadata. It is also mounted at /run/parent,
with all its extensions, so that pressure-vessel has the option of using
its graphics drivers (by populating the custom /usr with symlinks into
/run/parent and/or /run/host).
When doing this, we need to put an empty directory on /app, because
the real /app expects to be run on top of the real runtime. It would
also be reasonable to substitute a custom replacement for /app, so
I've included support for that too.
Partially addresses #3797.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is really just syntactic sugar for running `env -u VAR ... COMMAND`,
but env(1) is inconvenient when the form of the COMMAND is not known:
if the COMMAND might contain an equals sign, you end up having to run
`env -u VAR sh -c 'exec "$@"' sh COMMAND`. Let's make this simpler.
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>
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>
In addition to the old summary file we create a summary.idx and
a set of per-arch subsummaries (and extra copies of these if any commit
specify a subset). These are much smaller, and eventually we will also
get deltas for them.
We are not yet using these new formats, although the code is there
to use them once we start downloading them.
I'm not documenting the individual methods here, only the fact that the
interface exists and is private to the Flatpak source tree (it's the
communication between libflatpak and the system helper).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is based on documentation that I wrote for Steam's pressure-vessel,
which has a Launcher interface based on the API and implementation of
the Flatpak portal.
I haven't renamed exit_status to wait_status like commit 63feb3cc in
flatpak-xdg-utils, just in case the name is significant in someone's
code-generation. However, don't be fooled: it's a wait-status, not
an exit status.
Signed-off-by: Simon McVittie <smcv@collabora.com>
They aren't currently in any installed header file, but that doesn't
mean we can't suggest a name for dependent projects to #define.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Flags are assumed to be critical, similar to the convention for modern
Linux syscalls: if an unknown flag is given, the call will fail.
Callers are expected to guard their use of flags with a version check
or a fallback.
Conversely, options are assumed to be non-critical "hints", similar
to org.freedesktop.Notifications: if an unknown option is given, the
call will succeed as though the option had not been present. Callers
are expected to carry out an explicit version check if they need to
know whether an option is going to be respected or not.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This used to not be set for collection-id remotes as we used the
ostree-metadata branch for resolving. However, we now use the summary
always when doing a remote install (and not ostree-metadata for local
sideloads), so we still want to verify summary.
The signature on the summary is a nice security feature, but it is also
a very efficient small file to download to verify that no new summary
needs to be downloaded in the no-op update case.
For apps that run in the backgroun without interaction, pass this info
to the authenticator.
This can be used to avoid sending unnecessary webflow or basic auth
request, but those were already silenced by FlatpakTransaction. However
this also allows the authenticator to avoid doing direct, native user
interaction which was otherwise not avoidable.
This adds a new way for authenticators to trigger interactive authentication
in the client for simple user/password dialogs. These are not recommended
to use as a webflow is often better. However, for OCI remotes that
use http basic auth this is useful and allows the CLI experience to work
with that.
This adds the remote uri, and the per-ref commit id, as well
as extensible per-ref and per-request dicts we can add stuff to
as needed.
These will be used for the OCI case.
We can only support this if the host bwrap is not setuid (at least for
now). This allows callers to detect this case ahead of time. We also
detect this case when called and return a better error code that
can be detected.
This allows the authenticator to directly do UI and parent it to the
relevant window. The actual parent string is specified just like
the xdg-desktop-portal one.
There is a new flatpak_transaction_set_parent_window() function that
clients can use to signal the what window they want to be parented to.
This allows the authenticator to handle each token type differently.
For example, this allows a "purchase" type to run the donation
webflow, but not require login (and then store the fact that this was
run locally).
This makes it very easy to reuse a single authenticator for several
remotes. This is useful for the a default authenticator implementation
that we can ship with flatpak and use for e.g. flathub.
When resolving the transactions we call RequestRefTokens as needed
to get bearer tokens for some refs. These calls can also emit
the Webflow signal on the request object with a url. It is then
up to the client to show this url in some way.
Once the required operations are done in the browser it will redirect
to some url that will reach the authenticator, telling it that the
operation is done and the final result of it. At that point the
authenticator will emit the WebflowDone signal and continue.
If the cliend doesn't want to do the web flow it can call the close
operation on the request object.
This fixes compilation with GLib 2.63’s `gdbus-codegen`, which
automatically enables Unix FD support for D-Bus APIs which use the `h`
type, even if the `org.gtk.GDBus.C.UnixFD` annotation is missing.
By adding the annotation, the generated header whether using
`gdbus-codegen` 2.63 or < 2.63.
This is a slight API break in GLib, but it’s questionable about whether
flatpak should have always had the annotation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This allows an application to request it to be updated to the latest version.
The updates are done out-of-process by re-spawning the portal (via
/proc/self/exe) and proxying the relevant events over a socket pair, in
order to avoid any long term stability or memory requirements from
running the update operation.
This is a docker seccomp profile that allows you to run flatpak
inside a docker container, given some special requirements:
* The host kernel must support unprivileged user namespaces
(Supported by e.g. fedora and ubuntu kernels)
* The seccomp profile must be used
(--security-opt seccomp=flatpak-docker-seccomp.json)
* flatpak is run as a reguler user, not root, in the container
* The full host /proc must be visible in the container
(-v=/proc:/host/proc)
The last one is a bit weird, but the regular /proc in docker
is mounted with some cover-over mounts, and this makes the kernel
disallow mounting a new procfs for the pid namespace. Adding
in a full copy of the host fs causes this to be allowed.
Closes: #2867
Approved by: alexlarsson
end-of-lifed-with-rebase runs earlier in the transaction system than end-of-lifed, meaning it can modify the transaction for rebasing.
The new flatpak_transaction_add_rebase() function can then be used to apply the rebase if wanted.
Closes: #2775
Approved by: alexlarsson
If there is a pull failure in a child repo created on revokefs-fuse
mount, there is no way to go back to the system helper and notify
it to cleanup. Therefore, CancelPull is required on the pull failure
error path, so that the ongoing pull can be cleaned up nicely and
prevent any dangling mounts and subprocesses.
Closes: #2657
Approved by: alexlarsson
This adds a new helper method "GetRevokefsFd" which is responsible
for spawning the backend part of the revokefs filesystem. It takes care
of creating a cache location for the backing directory in repo/tmp.
This cache location is transferred over D-Bus to the client with the
other end socket fd.
The client on receiving the socket fd creates a mountpoint directory and
spawns the revokefs-fuse filesystem. It then creates a child repo for the
pull. In any case of failure, it fallbacks on the current code path
(which causes temporary duplication of files on disk).
The backing dir itself and all files written to it by the revokefs-fuse
backend process are owned by the "flatpak" user. After the pull in the
child repo is completed, it's ownership is then canoncalized with owner=root
and permissions as per bare-user-only in Deploy().
Now we have fulfilled all the criteria to hardlink the child repo into
the system one and avoid duplication. See [1].
If there is existing cache directory available in repo/tmp, it will be
mounted using revokefs-fuse for the current pull. Hence, it is possible
to recover the previous partial pull which might have failed due to some
error.
[1] https://github.com/ostreedev/ostree/pull/1776Closes: #2657
Approved by: alexlarsson
I could not work out at all how exposing files works,
until I looked at the code. Put enough details in the
docs to spare the next person this fate.
Closes: #2437
Approved by: alexlarsson
Some methods were missing a flags argument. This
will be a problem in the future, when we want to
pass a no-interaction flag to all methods. Therefore,
add an empty flags enum for every method that is lacking
one now.
This is an api change for the system-helper interface.
Closes: #2370
Approved by: alexlarsson
