Instead of running as root we setuid to the real user, after
having assured that we have the minimum amount of capabilities
required (which we then drop at the end).
This means we create all files as the actual user, and we never
risk somehow reading a file that otherwise only root could read.
This allows to restrict the access that the app gets out of
the sandbox. We allow an access if the app requests it (in its
metadata) and the user doesn't forbid it (with this option).
The --runtime option lets us completely override the runtime that
is specified in the application metadata. This is useful for testing
compatibility of an application with runtimes.
This will be used later to avoid deleting active mounts.
They have to be created during deploy, because we are
then guaranteed to be able to write to the directory,
and we don't want the resulting file to be hardlinked
to any other deployment (as then locks could be shared).
For the fully sandboxed case we *need* a pid sandbox, so we might as
well always use one to get the same setup always. There should really
be no need for a normal "app" to see host processes.
The other nice thing about this is that we get somewhere to run code
when the app stops, which means we can do things like delay uninstall
while apps are running.
The unfortunate drawback of this is that we get 2 extra processes per
app, one is the pid1 in the sandbox, and the other is the monitor
process to return the exit code to the spawner of xdg-appp-helper.
Rather than do the fork workaround we make / rslave, which means
we will still get new mounts/unmounts propagated to us from the root,
but will not leak any mounts to the host.
We also use a single directory in the users run dir as the mountpoint
for the tmpfs.
This is a small app that makes copies of various system files to a directory
in /run so that the app sandbox can receive updates to these. This solves
the issue that we can't generally bind-mount say /etc/resolv.conf, because
it will be replaced with rename-over.
This makes /etc a real directory, with required files like passwd and
symlinks to all the other files in usr/etc.
This is required because we need to make /etc/localtime an actual
symlink whose value depends on the host state.
Make it so that one can specify --user or --system to list
only items from one location, but if neither is specified,
both user and system items are listed.
This is a natural counterpart to --user with the opposite
meaning. In the future, we may start interpreting the absence
of either as 'operate on both'.
