RootImageOptions=/ExtensionImages=/MountImages= all support custom
mount options, but mountfsd does not support it. Add varlink
parameters to allow callers to specify mount options so that
those directives can work as expected.
Given the security implications of some mount options (e.g.: ACLs,
SELinux), require additional privileges to use custom mount options.
Pass the list of requested options to polkit details, so that the
policy can check the exact details if needed, for example to only
allow nosuid and reject the rest.
So far we expected the client to access the access mode themselves, and
set a restrictive 0700 server-side.
However, in some scenarios it's handy if the inode is created
server-side already with the right mode, in particular when the client
doesn't do anything with the dir just yet, and just needs it to be there
with the right mode. If it has to adjust the mode client-side it might
otherwise need to fork something off, join the selected userns, adjust
the mode, and kill the child off again.
In many cases we want to expose enums for which we have the usual
xyz_to_string()/xyz_from_string() via Varlink as enums. Let's add some
infra to test the tables against each other, to automatically detect
when they deviate.
In order to implement this properly, let's export/introduce clean
json_underscorefy()/json_dashify(), for dealing with the fact that our
enums usually use dash separates ames, but Varlink doesn't allow that.
(This does not add the test cases for all enum types we expose right
now, but only adds the general infra).
In order to fully support unpriv containers placed in directories owned
by the foreign UID range, below some unpriv user $HOME, we need to away
to actually create these hierarchies in the first place.
Let's add a method call for that. It takes a dir fd, then validates that
its ownership matches the client's identity, and then creates a subdir,
chown()ing it to the foreign UID range. It then returns an fd to the
result.
The result could then be passed to MountDirectory() in order to get a
mount which can then be populated by some code running in a dynamic
userns.
When mounting a disk image we return a bunch of mount fds referencing
the various partitions in the disk, along with some metadata about them.
One key metadata field is the "designator" which is supposed to tell
clients what is what, and where to mount it.
Let's make this more explicit: let's also include the literal relative
path where each mount shall be placed, to simplify implementations of
clients that do not care about the concept of designators.
systemd-mountfsd so far provided a MountImage() API call for mounting a
disk image and returning a set of mount fds. This complements the API
with a new MountDirectory() API call, that operates on a directory
instead of an image file. Now, what makes this interesting is that it
applies an idmapping from the foreign UID range to the provided target
userns – and in which case unpriveleged operation is allowed (well,
under some conditions: in particular the client must own a parent dir of
the provided path).
This allows container managers to run fully unprivileged from
directories – as long as those directories are owned by the foreign UID
range. Basic operation is like this:
1. acquire a transient userns from systemd-nsresourced with 64K users
2. ask systemd-mountfsd for an idmapped mount of the container dir
matching that userns
3. join the userns and bind the mount fd as root.
Note that we have to drop various sandboxing knobs from the mountfsd
service file for this to work, since the kernel's security checks that
try to ensure than an obstructed /proc/ cannot be circumvented via
mounting a new procfs will otherwise prohibit mountfsd to duplicate the
mounts properly.
It's time. sd-json was already done earlier in this cycle, let's now
make sd-varlink public too.
This is mostly just a search/replace job of epical proportions.
I left some functions internal (mostly IDL handling), and I turned some
static inline calls into regular calls.
Luca Boccassi
Lennart Poettering
Yu Watanabe