nspawn: optionally, automatically allocate a UID/GID range for userns containers

This adds the new value "pick" to --private-users=. When specified a new
UID/GID range of 65536 users is automatically and randomly allocated from the
host range 0x00080000-0xDFFF0000 and used for the container. The setting
implies --private-users-chown, so that container directory is recursively
chown()ed to the newly allocated UID/GID range, if that's necessary. As an
optimization before picking a randomized UID/GID the UID of the container's
root directory is used as starting point and used if currently not used
otherwise.

To protect against using the same UID/GID range multiple times a few mechanisms
are in place:

- The first and the last UID and GID of the range are checked with getpwuid()
  and getgrgid(). If an entry already exists a different range is picked. Note
  that by "last" UID the user 65534 is used, as 65535 is the 16bit (uid_t) -1.

- A lock file for the range is taken in /run/systemd/nspawn-uid/. Since the
  ranges are taken in a non-overlapping fashion, and always start on 64K
  boundaries this allows us to maintain a single lock file for each range that
  can be randomly picked. This protects nspawn from picking the same range in
  two parallel instances.

- If possible the /etc/passwd lock file is taken while a new range is selected
  until the container is up. This means adduser/addgroup should safely avoid
  the range as long as nss-mymachines is used, since the allocated range will
  then show up in the user database.

The UID/GID range nspawn picks from is compiled in and not configurable at the
moment. That should probably stay that way, since we already provide ways how
users can pick their own ranges manually if they don't like the automatic
logic.

The new --private-users=pick logic makes user namespacing pretty useful now, as
it relieves the user from managing UID/GID ranges.

0 files changed, 0 insertions, 0 deletions