It seems OSTree switched back to 0 for mtimes, so we have to switch
back too. We need to depend on this release to ensure that all
created repos gets things right.
This is no longer needed, as we don't hard-require systemd --user.
We keep the opion there, but hidden in order to be backwards compatible
with old code that used this.
This has two advantages. First of all (and most important) it
lets us put a /.flatpak-info file in it, so that the dbus peers
it talks to have the right "source" app id and sandboxed status.
Secondly, it lets us run the bus with readonly access to things,
thus being somewhat more secure.
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.
Alexander Larsson