linux: support supplementary groups with auto-allocate-uids

[SimSaladin]

Motivation

Add a new option "supplementary-groups" that allows specifying additional groups to be mapped into the build sandbox and assigned as supplementary groups for the build user.

This makes it possible to, for example, use the "kvm" group to provide access to /dev/kvm (without giving world-write to it) even when auto-allocate-uids is enabled—something that was not previously possible. It also enables use of supplementary groups to grant sandboxed builds group-controlled access to secrets or other shared resources.

Context

Closes: #9276

What I'm not at all sure of is whether having kvm (or anything) mapped by default is sensible or not.

The code is already calling setgroups anyway, a default perhaps wouldn't really break anything for anyone, and kvm assigned by default (if it exists) might save someone from the trouble of hunting down that one piece of UDEV rule logic... or was it libvirt itself that changed /dev/kvm perms if it felt like it sometimes? Or perhaps the systemd unit... I mean, well, this is now the future where my /dev/kvm is 0666 root:kvm as a default. So I suppose then that someone finally found way to fix that "permission denied" error for everyone. Neat!

Note, kvm the system-feature is already on by default.

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[edolstra]

This should probably be a JSON option, similar to #13315 (comment).

E.g.

extra-supplementary-groups = [ {"group": "nixbld"}, {"group": "users", "gid": 10100} ]

[edolstra]

What's the use case for adding nixbld as a supplementary group? Isn't the build user already running in the nixbld group?

[SimSaladin]

Indeed, this doesn't change anything if build-users-group = nixbld and auto-allocate-uids = false.

But if (1) build-users-group was something else than nixbld, then nixbld here should be interpreted as a supplementary group (primary group being whatever the host has assigned for the builder mapped to sandbox nixbld/100). It has a GID that is inherited from the host, and it (or the sandbox-mapped GID, if mapping was added) should be present in build user's sup. groups. (Currently this case is ignored.)

Secondly, (2) when auto-allocate-uids is active the host-side GID of sandbox nixbld group is a huge generated one, so it's a totally different group (save for the identical name) from the nixbld group that is referred to here (which is, of course, the group that's called nixbld and has some well-known static GID (e.g. 30000) in the host's (usually root) namespace ... well, assuming that such a group exists of course).

Most importantly, it's a group for which one is able to grant permissions in a filesystem, bind-mount said fs into the sandbox, and so provide fs access - without 777 - for builders through group permissions. Without auto-allocate-uids, the host-side primary GID is already the permitted group, usually, and nothing more needs to be done. Otherwise however, a setting like this becomes necessary so that the permitted GID may be mapped for the builder that has only some random high UID/GID by default.

A permissioned nixbld supplementary group (in the presence of auto-allocated UIDs) is perhaps the main use of this setting.

[edolstra]

I guess "user definitions" refers to /etc/group here? Wasn't entirely clear.

Also, wouldn't it make sense to apply supplementary-groups regardless of whether we're using auto-allocate-uids? The only thing that wouldn't work is the gid remapping.

[SimSaladin]

That's correct. I'll revise the wording.

No argument there, this is now only focused to the auto-allocate-uids case because that's the simpler situation. Build users also technically have their individual groups as well when the users are defined in the host's user database.

[SimSaladin]

The current changeset now enables supplementary groups regardless of the auto-allocate-uids setting.

When static build users are used, additional groups that the build user is a member of are mapped automatically. (Not sure whether this should be opt-in instead? Adding additional groups for build users is kind of intentional already.)

Some of the changes here go beyond managing supplementary groups now. This is to facilitate idmapping for bind mounts as implemented here: SimSaladin@3351c65. That feature builds on top of #13315 and also this PR.