libstore: fix auto-allocate-uids for non-sandboxed builds

[KiaraGrouwstra]

Motivation

Allow unsandboxed builds using auto-allocate-uids to fall back to nixbld users.

Closes #9761.

Context

Where auto-allocate-uids is enabled, builds that cannot be sandboxed (e.g. derivations with __noChroot = true, or with sandbox = false) were setuid'd to an auto-allocated UID with no entry in the host's /etc/passwd. /etc/passwd is only fabricated inside the chroot, so outside the user namespace whoami, getpwuid(), podman and ssh all fail, breaking nixpkgs packages like spago-legacy, generic-stack-builder and xcodeenv.

Auto-allocated UIDs only make sense inside a user namespace where Nix controls /etc/passwd. For non-sandboxed builds, fall back to a real nixbld user via build-users-group if one is configured; otherwise fail with a clear error pointing at sandboxing or build-users-group rather than silently running as an unknown UID.

Disclaimer: I used a coding agent in the creation of this patch.

[xokdvium]

Should we just fail unconditionally? That would make much more sense.

[KiaraGrouwstra]

@xokdvium conceptually, i would then regard the auto-allocate-uids feature, particularly if we are to take into account the scenario of it eventually stabilizing, as enabling rather than forcing use of auto-allocated UIDs, with unsandboxed builds then opting to, with valid reason, not to make use of it.

[xokdvium]

I might be misunderstanding, but the whole purpose of the feature is to not have the explicitly configured users at all. You can happen to have some stale users from prior install, but I'd imagine new installs that only do auto-allocate-uids wouldn't have it.

Also, if somebody wants to use unsandboxed builds they probably shouldn't be running auto-allocate-UIDs in the first place – those would be fully incompatible features.

[KiaraGrouwstra]

if somebody wants to use unsandboxed builds they probably shouldn't be running auto-allocate-UIDs in the first place – those would be fully incompatible features.

nixpkgs has like a dozen packages that opted out of the sandbox.
would you then argue that, presuming those need to be built unsandboxed, the ability to auto-allocate UIDs should never stabilize?

[xokdvium]

UIDs should never stabilize?

Hm, I don't really get what you mean? Enabling/disabling the feature doesn't interact with the feature itself being stable. Disabling the sandbox isn't a default configuration too.

Btw, another curious avenue to have auto-allocate-uids be run as users that work with nss is nsresourced (@artemist had a working implementation for that - #15103, not sure about the status of it, but it seems promising).

systemd-nsresourced automatically ensures that any registered UID ranges show up in the system's NSS database via the User/Group Record Lookup API via Varlink.

I wonder if it would be possible to only enter a userns (provided by nsresourced), while bypassing mount namespaces. Would that work in the scenario you had in mind?