Switch to UID 351+ and GID 350 on macOS

[emilazy]

We’ve finally bikeshedded final values for the new macOS UID/GID values to handle the Sequoia issues; an Apple devrel suggested the range above 350 and we have refined that to 351+ (i.e. _nixbld1 having UID 351, etc.) to avoid an off‐by‐one compared to the previous UIDs and the Linux UIDs, and to maintain the correspondence between the last digit of the build user names and the last digit of their UIDs.

We are also switching new installs to use GID 350, to align with the new UIDs (without overlapping them, as before and on Linux), because using a GID in the system range avoids the Nix build users group cluttering up System Settings.

Hopefully you can align with upstream Nix on this so that we can all be on the same page and finally put this issue behind us! (Except, uh, every installation is still going to break on upgrade. I don’t suppose you’re in a better position than upstream to make an automatic migration happen? We have a script, but informing people they need to run it is another thing…)

See also: NixOS/nix#10919 (comment), NixOS/nix#11372, abathur/nix#15.

[emilazy]

Also, just to clarify: Nix is going to use these values for all macOS installations going forward, not just ones on Sequoia+ (since that would present the same migration hazard as well as be needlessly inconsistent).

[cole-h]

Thanks for opening this issue to remind us!

---

[...] (Except, uh, every installation is still going to break on upgrade. I don’t suppose you’re in a better position than upstream to make an automatic migration happen? We have a script, but informing people they need to run it is another thing…)

(TL;DR of the below: New installs of whatever version that includes this new (pending) repair functionality will be robust against the upgrade to Sequoia by default. However, we'll still need to communicate to our users on older installs that they'll need to run repair from a newer nix-installer binary at some point before they run their first Nix command on Sequoia; whether that's before they even take the upgrade, or after.)

In versions of the installer >=0.14.0, we have a repair subcommand that we could add this to (mostly-only useful on macOS), and on macOS we create a hook service that calls this on every boot (which is how we get Nix to survive minor macOS updates -- by re-adding the shell hooks when the launchd unit is run).

Figuring out the right logic may not be that trivial, but I do believe it's possible :)

The good news is: repair doesn't do a version check with the existing receipt, so once we come up with a way to detect the system doesn't have the UIDs in the right place (so we don't delete-recreate the build users every boot), we can add the logic there, since the migration would be easy to do via curl https://install.determinate.systems/nix/tag/vX.Y.Z | sh -s -- repair.

As for the logic, it should be as trivial as deleting the existing build users and then creating the new ones against the old GID (I'll double-check the migration script upstream to ensure I'm not missing anything). (I am not comfortable changing the GID at the same time for similar reasons as expressed in abathur's comment here: NixOS/nix#11075 (comment).)

---

Also, just to clarify: Nix is going to use these values for all macOS installations going forward, not just ones on Sequoia+ (since that would present the same migration hazard as well as be needlessly inconsistent).

Yep, 100% agree with that -- all new installations should get these values by default. The reason we didn't do that when doing the temporary workaround is because we figured the upstream scripts might come to a different conclusion (as they did).

[emilazy]

Sounds good to me, thanks for explaining the plan! Is the idea to switch the default UIDs/GID before implementing migration logic for old installations, or will it all land at once?

[cole-h]

I'll probably do the requisite changes in two separate PRs, but they'll be released in the same version bump.

[cole-h]

I'll probably do the requisite changes in two separate PRs, but they'll be released in the same version bump.

(I was wrong -- the first change of setting the new base UID/GID was released in https://github.com/DeterminateSystems/nix-installer/releases/tag/v0.23.0, and I'm still working on the migration tool)

[cole-h]

I've got a draft PR that implements the sequoia repair subcommand up at #1143.

I still have some more testing to do, but so far I'm mostly satisfied with how it works. Feel free to take a look (at the code or at actually using it).

The default repair subcommand is still to repair the shell hooks (nix-installer repair == nix-installer repair hooks). To run the sequoia repair process, run nix-installer repair sequoia. If you're not on macOS 15 Sequoia yet, you'll want to pass the --move-existing-users flag (this was a compromise with the goal of making subsequent runs of the repair do nothing when all the users still exist because we already migrated them before).

[emilazy]

@cole-h Do you know how soon the repair command for this is going to release? Sequoia’s release is scheduled for Monday and I am trying to get automated detection in nix-darwin to point users to the migration options ASAP before the update lands and breaks everyone’s installation. I think that is the highest‐impact thing we can do to mitigate the support burden and reputation hit the Sequoia release is going to represent for us, and the sooner I can land it the more people will be able to fix their installations before they break.

I am reluctant to point people to the upstream Nix migration script unconditionally because it will cause the UIDs used to differ from what is in the receipt.json for installs using this installer, and I worry that will break uninstallation, but if you can confirm it can handle uninstallation after unexpected UID changes then I can do that.

[cole-h]

(I answered this in the "Nix on macOS" matrix room, but paraphrasing for posterity)

My goal is to cut the release before/on Thursday, and do our standard rollout procedure (which will take no longer than a day).

In my PR, I do make an effort to update the UIDs in the receipt if the receipt is valid and parseable. This is kinda of dubious benefit: it'll only be able to update the UIDs if you're using nix-installer repair sequoia from the same version you installed with, and at this point all versions with the repair command will have the base UIDs default to 350 (+1 for first build user). It feels like the right thing to do (best-effort), though.

However, that doesn't really matter -- we remove users by their name, not by their UID:

nix-installer/src/action/base/create_user.rs

Line 319 in 7ed9e26

command.args([".", "-delete", &format!("/Users/{}", name)]);

(This holds true for Linux as well, where we use userdel/deluser by name)

[cynddl]

I'm not sure the repair command is working?

After running the repair command, I now get the following error message:

error: Build users have unexpected UIDs, aborting activation
The default Nix build user ID range has been adjusted for
compatibility with macOS Sequoia 15. Your _nixbld1 user currently has
UID 351 rather than the new default of 351.

It does migrate users but nix nevertheless blocks execution with a "correct" UID.

[emilazy]

Hi @cynddl, that’s our (nix-darwin) message, not a Nix one. The wording might be slightly confusing because I’m guessing you have a non‐standard configuration that’s causing this issue – do you set ids.uids.nixbld anywhere in your nix-darwin configuration?

[cynddl]

Thanks @emilazy! I had indeed set ids.uids.nixbld (to a number different from 351 though…). Removing the line fixed the issue. :)

[emilazy]

Good to know! We should maybe refine the error message in the case where it’s set to a custom value; I just kind of assumed that nobody did.