a527bb251a
We offer full cgroup delegation to our sandbox now, required for running containers inside the sandbox. To run systemd-nspawn or containers managers inside the sandbox, there is a need for one extra ingredient now: control over your own cgroup subtree inside the sandbox. If, in addition, you need multiple UIDs, for e.g. rootless usecases, you need to run with the `uid-range` system feature. Therefore, when the daemon or Nix runs under the right condition, e.g. systemd-style delegation of the cgroup subtree while placing the nix-daemon in a supervisor sub-cgroup, we create a new sub-cgroup for each build based on the build UID and delegate that sub-cgroup to the builder's process. Additionally, `uid-range` always request the `cgroups` feature now, as `uid-range` builds would probably always benefit from having cgroups delegated, but the converse is not true. Inspired from https://github.com/NixOS/nix/pull/11412 with a different design that does not use function-local statics to derive the root cgroup. Co-authored-by: Linus Heckemann <git@sphalerite.org> Co-authored-by: Parker Hoyes <contact@parkerhoyes.com> Change-Id: Ic8947c5adaf4b5bbd153386e05fad65a935274fa Signed-off-by: Raito Bezarius <raito@lix.systems>
451 B
451 B
synopsis, issues, cls, category, credits
| synopsis | issues | cls | category | credits | |||
|---|---|---|---|---|---|---|---|
| uid-range depends on cgroups |
|
Breaking Changes |
|
uid-range builds now depends on cgroups, an experimental feature.
uid-range builds already depended upon auto-allocate-uids, another experimental feature.
The rationale for doing so is that uid-range provides a sandbox with many
UIDs, this is useful for re-mapping them into a nested namespace, e.g. a
container.