Let's not leak details from src/shared and src/libsystemd into
src/basic, even though you can't actually do anything useful with
just forward declarations from src/shared.
The sd-forward.h header is put in src/libsystemd/sd-common as we
don't have a directory for shared internal headers for libsystemd
yet.
Let's also rename forward.h to basic-forward.h to keep things
self-explanatory.
Aside from the usual boilerplate of moving the shared logic to shared/,
we also rework the implementation of --bind-user= to be similar to what
we'll do in systemd-vmspawn. Instead of messing with the nspawn container
user namespace, we use idmapped mounts to map the user's home directory on
the host to the mapped uid in the container.
Ideally we'd also use the "userdb.transient" credentials to provision the
user records, but this would only work for booted containers, whereas the
current logic works for non-booted containers as well.
Aside from being similar to how we'll implement --bind-user= in vmspawn,
using idmapped mounts also allows supporting --bind-user= without having to
use --private-users=.
Prior to this change, no user shell can be specified in the user
records passed into a container via --bind-user=. This new option
allows users to:
1. When false (the default), continue to specify no user shell for
each bound user record, resulting in the use of the container's
default shell for bound users.
2. When true, include each host user's shell in the corresponding
user record passed into a container (via --bind-user=).
3. When an absolute path, set that path as the user shell for each
user record passed into a container (via --bind-user=).
This does not change the existing behavior, but allows users to
opt-in to either copy the shells specified by the host user records
or override the shell explicitly by path.
This new option does three things for a host user specified via
--bind-user=:
1. Bind mount the home directory from the host directory into
/run/host/home/<username>
2. Install an additional user namepace UID/GID mapping mapping the host
UID/GID of the host user to an unused one from the container in the range
60514…60577.
3. Synthesize a user/group record for the user/group under the same name
as on the host, with minimized information, and the UID/GID set to
the mapped UID/GID. This data is written to /run/host/userdb/ where
nss-system will pick it up.
This should make sharing users and home directories from host into the
container pretty seamless, under some conditions:
1. User namespacing must be used.
2. The host UID/GID of the user/group cannot be in the range assigned to
the container (kernel already refuses this, as this would mean two
host UIDs/GIDs might end up being mapped to the same continer
UID/GID.
3. There's a free UID/GID in the aforementioned range in the container,
and the name of the user/group is not used in the container.
4. Container payload is new enough to include an nss-systemd version
that picks up records from /run/host/userdb/