An assertion failure that says res is FALSE is a lot less useful
than an assertion failure that says we got a specific GError.
Signed-off-by: Simon McVittie <smcv@debian.org>
The info file is always standalone, as it never needs to stack on top
of another context. This means we can remove all "negative" attributes
such as "shared=!network", making it easier to parse this file.
The old location keeps working because we create a symlink.
The interesting part of this is that the sandbox now can't modify,
remove or replace the file, and it is in a fixed position. This means
that given a sandboxed pid, we can find this file as
"/proc/$pid/root/.flatpak-info".
This is very nice for two reasons:
* We can use this instead of the cgroup to find out if a pid is
sandboxed or not. This means we can drop the dependency on
systemd --user for this.
* We can get more information about the peer process that the
app id. For instance, we can see what permissions the sandboxed
app has.
This way you can e.g. do network i/o in them.
Thats not a recommended way to do it though, as you work around
a lot of the feature in flatpak-builder like the caching and
verification.
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.)
This enables support for ptrace and perf for the app, similar
to what run -d manually gave you before. This is nice to be
able to package an app like gnome-software.
This was using libflatpak which is the public API, instead of the internal
library, so it was breaking in all sorts of mysterious ways. This is fixed
by just directly calling the lowlevel common/* APIs.
Also, it didn't properly handle the case where the sandboxed app passed a
path that was not in /app, this should be allowed if the fd validation
passes, that is the whole point of the checks after all.
If there are multiple refs pointing to the same revision, then
collecting the size and metadata info for each of them is wasteful.
Maintain a hash table of the data so that it's only collected once per
revision.
This slightly widens an existing race where a ref could be updated
before the summary file is regenerated. In that case, the data in the
xa.cache variant would correspond to the wrong revision. I don't believe
this can be fixed unless there's locking at the ostree level.
If there are non-flatpak refs in the ostree repo, there's no use in
collecting size or metadata information for them. Instead, only operate
on refs in the appstream, app or runtime prefixes.
This is already called automatically from flatpak_dir_deploy_update.
In particular, in the system-installed case this will cause
a warning due to not being able to remove the old checkout with
permission denied.
Simon McVittie