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
These document id will not be shared for multiple users. The main
difference is this this makes it safe for the creating app to delete
the document if he wants to (i.e. for temporary docs), and thus we can
grant this additional permission for the calling app.
In order to be robust against symlink attacks (i.e. make a document
for a path, then replace it with a symlink somewhere else and have the
portal read that instead) we store the parent dev/ino when we create
the document id and always verify that (atomically with the *at
syscalls) on each use.
Also, we pass O_PATH fds when creating documents, as it allows us
to be a bit safer. For instance we can verify that the fd is a O_PATH
fd before doing any ops on it, and it makes it possible to avoid other
symlink trickery.
Also, we drop the double add methods, and just use the O_PATH version.
This moves a all source code into separate subdirs per binary. The
helper and the generic stuff goes into lib/ which is then used by all
the others. For now this is a completely internal library, but at
some point we will probably clean it up and expose some subset.
Also, we move the dbus proxy to libexecdir.
