Switch to UID 351+ and GID 350 on macOS #24

Closed
opened 2024-09-10 15:43:02 +00:00 by emilazy · 10 comments
Member

macOS Sequoia will release on Monday and break the majority of existing installations as well as all new ones using the current UIDs/GID. The ecosystem is standardizing on UIDs 351+ for the build users and GID 350 for new installations on macOS. Current installations can keep the old GID but must have their UIDs migrated for Sequoia compatibility.

See https://github.com/NixOS/nix/pull/10919 and https://github.com/NixOS/nix/pull/11075 for where the values were settled upon (with some help from an Apple devrel) and a shell migration script was implemented (which should work for Lix users at a pinch).

This has already been implemented upstream in Determinate Systems’ installer and they are working on a command to repair existing installations; see https://github.com/DeterminateSystems/nix-installer/issues/1115. Hopefully you can backport their change ASAP so that new installations work after Sequoia’s release, and the repair command is meant to ship Thursday or earlier. I’m not sure if you’re in a position to signal users that their installation will break before it does, but I’m currently implementing that in nix-darwin. (It would be helpful to know if there is a canonical way to detect whether an installation was installed with lix-installer, esp. to disambiguate it from the Determinate Systems installer.)

This would fix #18, but I wanted to track the more concrete thing here especially since it’s high‐priority.

macOS Sequoia will release on Monday and break the majority of existing installations as well as all new ones using the current UIDs/GID. The ecosystem is standardizing on UIDs 351+ for the build users and GID 350 for new installations on macOS. Current installations can keep the old GID but must have their UIDs migrated for Sequoia compatibility. See https://github.com/NixOS/nix/pull/10919 and https://github.com/NixOS/nix/pull/11075 for where the values were settled upon (with some help from an Apple devrel) and a shell migration script was implemented (which should work for Lix users at a pinch). This has already been implemented upstream in Determinate Systems’ installer and they are working on a command to repair existing installations; see https://github.com/DeterminateSystems/nix-installer/issues/1115. Hopefully you can backport their change ASAP so that new installations work after Sequoia’s release, and the repair command is meant to ship Thursday or earlier. I’m not sure if you’re in a position to signal users that their installation will break before it does, but I’m currently implementing that in nix-darwin. (It would be helpful to know if there is a canonical way to detect whether an installation was installed with `lix-installer`, esp. to disambiguate it from the Determinate Systems installer.) This would fix https://git.lix.systems/lix-project/lix-installer/issues/18, but I wanted to track the more concrete thing here especially since it’s high‐priority.
Author
Member

Note also that existing installs are fine to remain on GID 30000. The move to GID 350 at the same time was to solve a cosmetic problem with the Nix build user group showing up in System Settings, and for consistency with the UIDs. The upstream migration script does not change the GID because of worries about interfering with existing file ownership in /nix. I don’t know what Determinate Systems’ plans are regarding group migration, but I would expect the same.

Note also that existing installs are fine to remain on GID 30000. The move to GID 350 at the same time was to solve a cosmetic problem with the Nix build user group showing up in System Settings, and for consistency with the UIDs. The upstream migration script does not change the GID because of worries about interfering with existing file ownership in `/nix`. I don’t know what Determinate Systems’ plans are regarding group migration, but I would expect the same.
Owner

blegh. thank you for reporting this.

blegh. thank you for reporting this.
Member

This issue was mentioned on Gerrit on the following CLs:

  • commit message in cl/1906 ("[Nix#11075] Add script to migrate macOS 15 Sequoia nixbld UIDs")
  • commit message in cl/1907 ("[DetSys#1123] Synchronize macOS UIDs and GIDs with upstream scripts to prepare for Sequoia")
  • commit message in cl/1913 ("store: add a hint on how to fix Lix installs broken by macOS Sequoia")
<!-- GERRIT_LINKBOT: {"cls": [{"backlink": "https://gerrit.lix.systems/c/lix/+/1906", "number": 1906, "kind": "commit message"}, {"backlink": "https://gerrit.lix.systems/c/lix-installer/+/1907", "number": 1907, "kind": "commit message"}, {"backlink": "https://gerrit.lix.systems/c/lix/+/1913", "number": 1913, "kind": "commit message"}], "cl_meta": {"1906": {"change_title": "[Nix#11075] Add script to migrate macOS 15 Sequoia nixbld UIDs"}, "1907": {"change_title": "[DetSys#1123] Synchronize macOS UIDs and GIDs with upstream scripts to prepare for Sequoia"}, "1913": {"change_title": "store: add a hint on how to fix Lix installs broken by macOS Sequoia"}}} --> This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/1906](https://gerrit.lix.systems/c/lix/+/1906) ("[Nix#11075] Add script to migrate macOS 15 Sequoia nixbld UIDs") * commit message in [cl/1907](https://gerrit.lix.systems/c/lix-installer/+/1907) ("[DetSys#1123] Synchronize macOS UIDs and GIDs with upstream scripts to prepare for Sequoia") * commit message in [cl/1913](https://gerrit.lix.systems/c/lix/+/1913) ("store: add a hint on how to fix Lix installs broken by macOS Sequoia")
Author
Member

https://github.com/DeterminateSystems/nix-installer/pull/1143 has now been merged; @jade I think backporting that would probably be a better approach than backporting the Nix shell script.

Happy to point Lix users to it from the nix-darwin error message; do you know of a reliable way to distinguish a setup installed with the Determinate Systems installer from one installed with the Lix installer?

https://github.com/DeterminateSystems/nix-installer/pull/1143 has now been merged; @jade I think backporting that would probably be a better approach than backporting the Nix shell script. Happy to point Lix users to it from the nix-darwin error message; do you know of a reliable way to distinguish a setup installed with the Determinate Systems installer from one installed with the Lix installer?
Owner

check for /nix/lix-installer

check for /nix/lix-installer
Author
Member

Hmm, I thought that https://gerrit.lix.systems/c/lix-installer/+/1502 hadn’t yet landed so it was still installing as /nix/nix-installer?

#[tracing::instrument(level = "debug")]
async fn copy_self_to_nix_dir() -> Result<(), std::io::Error> {
let path = std::env::current_exe()?;
tokio::fs::copy(path, "/nix/nix-installer").await?;
tokio::fs::set_permissions("/nix/nix-installer", PermissionsExt::from_mode(0o0755)).await?;
Ok(())
}

Hmm, I thought that https://gerrit.lix.systems/c/lix-installer/+/1502 hadn’t yet landed so it was still installing as `/nix/nix-installer`? https://git.lix.systems/lix-project/lix-installer/src/commit/962d7bf7452998697eb6a5fecac11891a1d430ac/src/cli/subcommand/install.rs#L390-L396
Owner

fuck i feel so burned out

fuck i feel so burned out

Happy to point Lix users to it from the nix-darwin error message; do you know of a reliable way to distinguish a setup installed with the Determinate Systems installer from one installed with the Lix installer?

If the change is backported, assuming the Lix installer will be able to repair installations originally made with the DetSys installer, then I'd recommend checking whether nix.package is nix or lix as I expect there are a lot of folk like me who did a DetSys installation originally and then subsequently adopted Lix.

> Happy to point Lix users to it from the nix-darwin error message; do you know of a reliable way to distinguish a setup installed with the Determinate Systems installer from one installed with the Lix installer? If the change is backported, assuming the Lix installer will be able to repair installations originally made with the DetSys installer, then I'd recommend checking whether `nix.package` is nix or lix as I expect there are a lot of folk like me who did a DetSys installation originally and then subsequently adopted Lix.
Author
Member

I’m working on backporting the repair command.

I’m working on backporting the repair command.
Author
Member

https://gerrit.lix.systems/c/lix-installer/+/1912 should do it. (Though I’ve only built it, not tested.)

https://gerrit.lix.systems/c/lix-installer/+/1912 should do it. (Though I’ve only built it, not tested.)
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix-installer#24
No description provided.