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>
16 lines
451 B
Markdown
16 lines
451 B
Markdown
---
|
|
synopsis: uid-range depends on cgroups
|
|
issues: []
|
|
cls: [3230]
|
|
category: "Breaking Changes"
|
|
credits: [raito, horrors]
|
|
---
|
|
|
|
`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.
|