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.
