Having /var writable is pretty weird for a desktop app, this
is typically a system location. Instead of doing this
we assume the user writes writable data into ~/.var/app/$appid.
This means an app following this can run both as standalone or
as an xdg-app without changes.
If the app has access to the home directory, then this just works. If
it does not, then we ensure we have this directory in the volatile
home directory and then bind mount in the real directory there.
We also pre-create config/data/cache subdirectories in this
directory and set XDG_DATA/CONFIG/CACHE_HOME to point to them, which
means apps that use these "just work".
For builds, reproducability and not accidentally getting
the host environment details into the build is pretty important,
so we rebuild the entire environment, controlling exactly
what gets into it.
Instead of creating real device nodes we just bind mount the system
ones. This means that we require no mknod capabilities, which is good
in itself, but it also allows us to eventually run completely
unprivileged with user namespaces.
All exported regular files (not directories) need to have a filename
that starts with the application name, followed by either a dot or
any character that is invalid in an app name.
For instance, given an app name of org.gnome.gedit, these filenames
are exported:
org.gnome.gedit
org.gnome.gedit.png
org.gnome.gedit.plugin1.png
org.gnome.gedit-symbolic.svg (- is not a valid character)
However, these are not exported:
org.gnome.geditor
gedit.png
This has several advantages. First of all it ensures that there are no
conflicts between unrelated applications, secondly we also only allow
applications to install dbus services and desktop ids that are the
same as the app id, or sub-services of it.
Rather than keeping around a symlink to the temporary file we rename
the temporary over the original name. Also we keep all seen
files and temporary files in a hashtable so we don't accidentally
process anything twice.
There are several reasons to verify these. First of all
we use these as filename elements, so we need to sure that dangerous
things like "..", "/" etc don't appear in them.
Secondly, we want to guarantee that app names are valid dbus well
known bus names as they are used as app-ids in e.g. desktop files.
We also want to enforce the app name as prefix for exported files to
avoid conflicts. This means we disallow two-element names like
"org.gnome", and we disallow "-" in app names, so that "-" can be used
to separate the app name prefix from the rest of the filename. In
particular, this is important for icons, like
"org.gnome.app-symbolic.svg", where we want the only valid prefix to be
org.gnome.app.
When we add a remote, load the summary from the repository, and
use the title if there is one. This at the same time serves as
(minimal) validation of the repository url.
This allows you to set the privs for the helper via file
capabilities instead of setuid.
You can also set the mode to none, but then you have to
manually set either setuid or filecaps (for instance via
a packaging script).
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.
Alexander Larsson