Set NIX_FIRST_BUILD_UID to 30001 on macOS

[abhillman]

Motivation

Currently, the installer creates users starting with uid 301. This fails on recent macOS releases, because 301 is now used by the system:

% dscl . -search /Users UniqueID "301" 
_modelmanagerd		UniqueID = (
    301
)

Context

• Installing on MacOS fails when user UID is already in use #2242,
• Darwin: install script fails on user with conflicting UniqueID (multi-user mode) #2179,
• oh no! Jeeze, something went wrong #5928,
• nix install breaks on UID clash #6153,
• nix macOS install failed -UID clash- (Jamf conterolled enterprise machine) #9682
• add UID migration script for macOS Sequoia 15 #11075

Workaround

NIX_FIRST_BUILD_UID=30001 sh <(curl -L https://nixos.org/nix/install)

Notes

Starting at 30001 is currently done in install-systemd-multi-user.sh https://github.com/NixOS/nix/blob/b1effc9649e2c9103aa4b9f42fabb02b601bf80e/scripts/install-systemd-multi-user.sh#L7C51-L7C52.

Other PRs

Similar to #10919 except that this is (a) more minimal in scope (while still working) (b) obviates issues with future releases of macOS that could easily well use other uids in the 300-400 range

[roberth]

If I recall correctly from earlier discussions about service uids in the nix-darwin project, numbers < 500 are chosen because they are interpreted by macOS as internal or "system" UIDs as opposed to real users. It was also noted that macOS/darwin's own system users have underscores prefixed to them. Presumably this also helps with distinguishing them.
Do you observe any negative side effects from choosing this > 500 range?
Do these users show up in login or unlock screens, or in user admin settings?

[emilazy]

Yeah, this is just opening us back up to the same macOS upgrade issues that we used to have, I think. Unless Apple fixed all of those.

For context please see:

• macOS update "booted to Recovery" because "an error occurred migrating user data" on Big Sur/Monterey w/ multi-user Nix present  #4531
• fix nixbld user name/uid for macOS/darwin #4532

cc @abathur as well

[abathur]

I am not opposed to returning to 30k+ uids--it is certainly where we want to be, but i imagine we'd need at least:

1. ~proof the problem documented in primops/fromJSON: add error position in case of parse error #4351 was fixed for a reasonably large share of recent macos updates for it to make sense to reopen that can of worms.
2. Demonstrate that the build users don't show up in users & groups, which tends to annoy people.

[cole-h]

FYI, this is a very brittle check -- macOS sometimes decides to lie about the version for "compatibility". If this approach is accepted, you'll need to set SYSTEM_VERSION_COMPAT=0 in this invocation (see e.g. https://eclecticlight.co/2020/08/13/macos-version-numbering-isnt-so-simple/) to ensure you're getting the actual version and not the compatibility version.

[emilazy]

I’m not convinced that we can assume the update story is resolved as of Sequoia (like – I just want some reason to pick a cut‐off version for deciding high UIDs are okay, if we do decide that), and in general I’m moderately opposed to setting UIDs based on the installation system version precisely because of upgrades. The current state of this PR would continue to leave people installing between now and whenever they upgrade to Sequoia in a state of impending macOS upgrade doom.

[abhillman]

Thank you all for your comments. I realize this is more complex than I had anticipated and appreciate your conscientiousness. Closing to reduce noise.

[abhillman]

One option could be to merge this as it resolves issues with macOS 15 with the addition of SYSTEM_VERSION_COMPAT=0. That said, this of course does not resolve upgrade issues for users with existing nixbld users with uids in the 300 range. @emilazy wdyt?

[emilazy]

I appreciate you taking the initiative! My main worry with any quick‐fix solution like this is that it might be setting up Sequoia users for a repeat of the upgrade issues we had with the 30000‐range UIDs in future. We don’t have any good way of automatically running migration scripts for people who don’t use a system manager like nix-darwin, so any installation‐time decision we make has consequences potentially years down the line, hence the institutional conservatism we’ve developed around these sorts of things.

Using the same 451+ range Determinate Systems are temporarily going with on Sequoia might be a more viable interim solution, as it’s still within the magic range. But hopefully we can just commit to a universal value before the final release forces the issue.