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
The OCI support relies on downloading a json index and converting it
to a ostree-style summary, which we the use in all sorts of operations
in the client code. Currently this happens in the user code, which means
that it will fail (due to permissions) in the system installation case.
We could do the conversion as the user, but when eventually installing
something the system-helper will anyway do this download and
conversion, so that would only double the work and risk things going out
of sync. Also, the OCI index is not gpg signed, so we can't realy on
downloads done as the user.
So, the solution done here is to add a GenerateOciSummary
system-helper call which we use instead of directly generating the
oci summary.
This fixes https://github.com/flatpak/flatpak/issues/2350Closes: #2363
Approved by: matthiasclasen
These portals are under their own bus name and
object path, clarify this in the docs. For the
document portal, this is just a sync-up with
the master copy in the xdg-desktop-portal repo.
Closes: #2074
Approved by: alexlarsson
There have been some minor edits in the official version
of this in xdg-desktop-portal. Sync up the version here.
Closes: #2064
Approved by: alexlarsson
Apparently -- is not valid XML, so a nonbreakable space was added, but
that breaks gdbus-codegen, so lets just drop the dashes totally.
Closes: #1988
Approved by: alexlarsson
This system-helper method will allow flatpak to update the ostree repo
summary while running as a non-root user that's in the "sudo" group.
This will allow the `flatpak create-usb` command to work without
requiring the user to first run `sudo ostree summary -u`, and without
requiring the system to have `core.auto-update-summary` set to true in
the ostree repo config. This is also much more efficient than
`core.auto-update-summary` because it allows us to only update the
summary when we need it rather than after every transaction.
Generating the summary basically just involves traversing the repo to
enumerate all the refs and putting this information into a file, so I
don't think there are security concerns with allowing it to happen
without authentication.
Closes: #1945
Approved by: alexlarsson
This is used to create the /var/lib/flatpak repo if
needed so that other later operations work. We have
some partial support for it not working in various
operations (using the allow_empty argument) but
this is in no way complete. For example, this
can easily happen if you have a per-user installation
but no system one and then you run flatpak install
with no --user, then it will try to figure out
which one to use and die.
This adds the xml interface definition for
org.freedesktop.impl.portal.PermissionStore.
Subsequent commits will use this interface.
Closes: #1837
Approved by: alexlarsson
This moves the triggers from out of flatpak_install/update/uninstall
and instead calls them manually at all the sites that call this.
This allows FlatpakTransaction to only run the triggers once for the
entire operation.
Closes: #1743
Approved by: alexlarsson
This listens to org.freedesktop.portal.Flatpak and lets flatpak
sandboxes do flatpak specific things.
Initially this only allows access to "Spawn", which lets you start a
new copy of the current or latest version of the calling app,
optionally with sandboxing.
This allows the app to re-start itself with the latest version after
an update, and the sandboxing is useful for apps that want to manually
sandbox part of themselves.
You can also expose one or more subdirectories of
~/.var/app/$appid/sandbox/ to the app, read-write or read-only. This is
useful to communicate with the sandbox.
This is now in xdg-desktop-portal. We keep a version of the document
portal dbus XML so that we avoid weird build dependencies.
Flatpak itself is technically not dependent on the document portal,
but it is very much recommended that you use it.
Closes: #1398
Approved by: alexlarsson
This is a convenient function which can be used with flags, adding option to return
real path of the file we are trying to open in case the sandboxed app has access
to it. It also registers this file automatically to document store so there is no
need to call grant_permission() afterwards.
Closes: #1335
Approved by: alexlarsson
We might want to prune the repo from within the library or
the command line and may not be in a privileged context, so
we'll need to jump through the system helper to prune the refs.
Closes: #1034
Approved by: alexlarsson
This allows you to add multiple paths at the same time, plus
grant an app access to it, plus it returns the fuse mount path.
This allows you to avoid a lot of roundtrip in common cases.
We download the summary and send it to the system helper, it verifies
the checksum and applies the changes, with the same polkit permissions
required as for an app update (i.e. typically none).
This allows us to update metadata automatically, without permission
requests.
If the bundle contains an origin link we can now install related
things from it, such as locale data.
You can also build the bundle with --runtime-repo=URL, where the url
points to a flatpakrepo file for a repo with runtimes. This works
similar to the RuntimeRepo= feature in flatpakref files.
This lets any client, possibly in a sandbox if it has access to the
session helper, spawn a process on the host, outside any sandbox.
Clearly this is not something you typically want a sandboxed app to
do. However, it is sometimes very useful when using flatpak mainly
for distribution. For instance, an IDE needs to use this to launch a
flatpak build operation inside the sandbox. (Because otherwise recursive
calls to flatpak will not work.)
We want to let the flatpak command show more information.
These functions will not be allowed from inside the sandbox
to prevent leaking information to sandboxed applications.
Lookup: go from a file (handed in via an fd) to a document id
Info: return origin and permissions for an id
List: return information about all exported documents
