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.
Note that I copied this xdg-app blacklist into linux-user-chroot:
https://git.gnome.org/browse/linux-user-chroot/commit/?id=8cee4ab7345f126d1dec55b7ca1f28e8090a58d3
We should figure out a better way down the line to share code - maybe
we can share a setup-seccomp.c?
Possibly in the long run we'll end up with diverging blacklists, as
linux-user-chroot can be a lot more aggressive, as its primary
audience is build side, not generic applications. We'll see.
But in this patch I added a big comment on how we should share code,
and in particular credit sandstorm.io for some of these filters.
(Although they may have gotten some of them from Android or Chromium?)
Going back to the high level topic - let's add perf and ptrace to the
blacklist. We expect profiling to be done from a non-sandboxed
terminal, or a less-restricted IDE type process which can look at the
namespace of other apps and the desktop/kernel.
This fixes the build on GLib 2.42 at least - the conditionals for
g_strv_contains() weren't right. I'm trying to have libglnx also be a
centralized "glib backports" area, so having g_strv_contains() there
is better.