Change my mind: I still want single-user on macOS

[gaverhae]

With Nix 2.4, the install script for macOS no longer supports single-user installations. I think that’s a shame, as single-user install was one of the primary reasons I loved using Nix. Not needing to give a random install script from the internet sudo access was also a requirement for me to feel comfortable recommending Nix to people who don’t know it yet.

First of all, I do want to recognize the tremendous work that went into making the macOS install automated post-Catalina. I understand how hard that was, and I am by no means trying to undermine or underestimate the work that went into that. I also understand that setting up a volume for the user (as well as the configuration necessary to get that volume mounted early on in the OS boot process) requires sudo access and arguably major system changes, and I can see the reasoning that leads from that point to a multi-user install.

However, I don’t want a multi-user install. I’m willing to be convinced otherwise (hence this post), so here are the reasons why I currently prefer single-user:

1. From a security perspective, I can’t imagine any benefit to giving the Nix installer sudo access: single-user runs everything as my user, with no need for sudo at any point (assuming I arrange to start the install process with a writable-to-my-user /nix, which is a burden I’m willing to bear). That seems inherently safer than running the Nix install process with sudo access. I’m told there is “sandboxing”, but it’s unclear whether that applies to macOS, and besides, I don’t really see the point: if I don’t trust the build process of a Nix expression to run as my user, why should I trust the resulting binary either?
2. From a performance perspective (I have a very vague understanding that there may be more parallelism going on with multi-user), I just don’t care: I use Nix to provide me with stable binaries for tools I use, i.e. as a package manager and not as a build system. Therefore they change fairly infrequently and are usually available as binaries I can just download, so I’m happy to wait for packages to “build” when needed.
3. The multi-install seems a lot more invasive to my system: it creates new users and changes system files. It’s also pretty unclear from the docs how to uninstall it cleanly. The single-user install writes to well-defined directories under $HOME and to /nix, so it’s easy to wipe out if I want.

I understand why the installer might want to default to a multi-user install in a post-Catalina world, since in most cases you’d need to setup the volume anyway. But if there is already a writeable /nix, it would be nice if the installer could use that to allow for a single-user install.

So, convince me: what am I missing? What is wrong with the way I’m currently thinking about it? What are the advantages of a multi-user install that may balance out what I see as drawbacks? What am I misunderstanding for a drawback but is actually a good thing somehow?

[symphorien]

A lot of software likes to write where it’s installed. A very common one is python, to compile pyc files. Other include apps that can autoupdate with executables that won’t work wit nix-provided libs, etc.
With a single-user install, the store is writable, so this actually works, especially when running nix-installed software as root, and you gradually corrupt your store and void many of the guarantees nix is suppose to bring you. You can see that it really happens by running nix-store --verify --repair --check-content. Hash mismatches are likely to be reported.

[abathur]

Regardless of whether anyone persuades you or not, I want to focus less on the installer (since it has no agency here) and more on people + support.

It’s probably obvious enough that you can set up an unsupported configuration, download the installer, comment out the execution guards, and assume responsibility for troubleshooting.

People who want to install Nix are not all knowledgeable about their systems. I’ve seen posts from people who know ~nothing about the read-only root, T2, filevault, fstab, launchd, keychain, shell profile/PATH, etc. They tend to read the manual, installer --help, and installer output in light of the reasonable assumption that options work and are supported. If the options don’t work or the people can’t figure out how to use them, some of them will show up (here, GH, Matrix, etc.) for support. Some of those will be a chore (cranky, demanding, clueless, helpless, etc.)

I’ll follow up with a bit more context, but my general opinion is that it isn’t a good idea to provide obvious options that will bait some fraction of new users (who often have little to no idea whether they should pick single/multi user) into trying to manually set up and use unsupported configurations.

[pxc]

@gaverhae

(assuming I arrange to start the install process with a writable-to-my-user /nix , which is a burden I’m willing to bear). That seems inherently safer than running the Nix install process with sudo access

Even the old single-user installer sets up /nix using sudo, so it sounds like you want something different than what we used to have in place anyway. As far as safety: why/how are the manual’s instructions on verifying the Nix installer inadequate?

@gaverhae

The multi-install seems a lot more invasive to my system: it creates new users and changes system files. It’s also pretty unclear from the docs how to uninstall it cleanly. The single-user install writes to well-defined directories under $HOME and to /nix , so it’s easy to wipe out if I want.

I’m not sure the following argument is actually good, but: if you feel confident setting up a special volume for /nix and whatnot on your own (administering your macOS system yourself so that the installer doesn’t have to be so smart), shouldn’t you also be comfortable administering your system to remove after Nix is installed (e.g., to remove the nixbld users)?

I don’t know that these reasons will speak to you, but these are the reasons that I like the decision to switch to a multi-user installation by default:

1. It’s more NixOS-like. This makes it easier for people switching between Nix on macOS and Nix on NixOS to know what to expect, and makes it easier for folks who exclusively use one or the other to support each other.

2. Multi-user package management (without resort to containerization at runtime) is one of the distinguishing features of Nix. Not leveraging that OOTB makes it harder for users to appreciate the unique advantages of Nix, and also makes it harder to switch to a setup where they can take advantage of that feature once they’ve gotten started.

3. Modern operating systems are multi-user. Single-user behavior like Homebrew’s strikes me as bad design, and a trip back to the DOS days in a bad way. It leaves a bad impression.

4. Single-user mode is harder to support for important use cases like corporate environments, where you might SSH into a MacBook to offer support. In that case, having to log in as the user you’re supporting in order to have Nix commands work right seems wrong (definitely more invasive).

I’m not sure that any of the points I enumerated really make the case for outright removing support for single-user installations. But keep in mind that there have been discussions in the past of removing support for multi-user installations on non-NIxOS for similar concerns about the sustainability of supporting different base configurations for Nix itself. If the community only has the resources to thoroughly support one configuration, in my opinion it should be the configuration that is more versatile and more similar to NixOS.

Re: uninstallation: the Nix build users don’t get $HOME directories or show up for GUI login, so they don’t leave much clutter. IIRC there’s ongoing work for a comprehensive uninstaller, which is great. But in the meantime if you want something simpler that feels more like a native Unix tool than macOS’ dscl, you can use userdel from Pkgsrc’s user-darwin package. It’s just a POSIX sh wrapper around dscl, so you can just download it and run it. You can grab the scripts here. (Maybe it would be worth it to package that for Nixpkgs, if we don’t already?)

[abathur]

@abathur

I’ll follow up with a bit more context, but my general opinion is that it isn’t a good idea to provide obvious options that will bait some fraction of new users (who often have little to no idea whether they should pick single/multi user) into trying to manually set up and use unsupported configurations.

Some things I’d expect, based on a mix of experience from the initial Catalina fix in 2.3 and from regularly checking installer issues for the past year:

• If the option is there, people are going to assume it works and try to use it.
• If it has no special handling and just errors out trying to write the read-only root, they’re going to file issues.
• If it prints a big message telling them they’ll have to go pre-create a volume, they’ll look for someone to hold their hand. (Even if the message tells them they’re on their own).
• If they are using FileVault and get instructions from someone who isn’t aware of the encrypted volume / app-restore race condition, they’ll end up with a known-bad configuration.
• If they get instructions from someone who is aware of the race condition they’re going to think we’re nuts for asking them to do all of it by hand.
• Either class of instruction is probably not going to include any effort to detect and remediate weird pre-existing state.
• If someone who doesn’t know what they are doing follows bespoke instructions from some discourse/SO thread, blog post, or chat-room, they’re more likely to end up with unexpected state that is harder for both humans and tools to debug/support later, and to be very little help figuring out how or why it got that way.

[pxc]

I ‘liked’ this post because it was very informative, but all of that sucks.

For me, it does bridge the gap from ‘multi-user by default is good’ to ‘the installer should only support multi-user on macOS’. The decision seems well-considered.

[alexv]

@gaverhae

I understand why the installer might want to default to a multi-user install in a post-Catalina world, since in most cases you’d need to setup the volume anyway. But if there is already a writeable /nix , it would be nice if the installer could use that to allow for a single-user install.

This is very true - in the enterprise world (where hundreds or even thousands of laptops are managed by some central IT team) while it might be possible to get a permission to have one top-level directory (/nix) owned by the “end user”, it is absolutely out of question to let the said user touch anything under, say, /etc, run services as root, etc.

[abathur]

@alexv

while it might be possible to get a permission to have one top-level directory ( /nix ) owned by the “end user”, it is absolutely out of question to let the said user touch anything under, say, /etc

To clarify: at minimum, no macOS user on Catalina+ can have a /nix directory, regardless of the owning user, without modifying /etc/synthetic.conf. (edit: I’m oversimplifying a bit; IIRC there are technically other paths like disabling SIP.)

If they enjoy suffering the incompatibilities that come with a symlinked store, they can stop there. If they wouldn’t, they’ll also have to modify /etc/fstab to set up an auto-mounting volume. (and, if they’re a filevault user, they’ll need a LaunchDaemon to avoid race-condition issues).

These aren’t things we’re modifying for fun. We’re modifying them because it was this or stop claiming to support macOS and leave it to DIYers. (I don’t want to ping everyone in the GH issue/PR with a notification, but a complete read through the comments in nix#2925 and nix#3212 is a good start if you think I’m being hyperbolic about macOS support hanging in the balance).

[gaverhae]

Hi all,

Thanks for all the answers here — really informative.

@symphorien

You can see that it really happens by running nix-store --verify --repair --check-content . Hash mismatches are likely to be reported.

Ah, that’s good to know. Although I would imagine such badly behaved packages would not work at all with a multi-user install, so I’m not entirely sure whether I prefer a mangled Nix store or non-working software.

I tried that command on three of the machines I regularly use Nix on, and none of them reported any issue, so it looks like the packages I’m using are well-behaved on that front.

@pxc

Even the old single-user installer sets up /nix using sudo

Actually, that’s not quite true: the 2.3.16 installer, at least, will only create /nix with sudo if it does not already exist. If I have a writeable /nix, it’s happy to run without any sudo access at all.

@pxc

shouldn’t you also be comfortable administering your system to remove after Nix is installed (e.g., to remove the nixbld users)

Setting up a volume that works for my use-cases is pretty easy, but the main point here is I know exactly what I did and therefore I know how to undo it. Is there a place where everything the multi-user installer does is documented in such a way that I can completely undo it and be confident my machine is in the exact same state as if I’d never installed Nix? I’ve not found one, but if there is that would go a long way towards alleviating my issues with multi-user.

@pxc

these are the reasons that I like the decision to switch to a multi-user installation by default:

I entirely support the move to multi-user by default, so I don’t really need convincing on that one. What saddens me is the outright removal of single-user as an option.

@abathur

To clarify: at minimum, no macOS user on Catalina+ can have a /nix directory, regardless of the owning user, without modifying /etc/synthetic.conf .

Sure, but setting up /etc/synthetic.conf and /etc/fstab can be done centrally by IT. What’s generally not acceptable is for users to have direct access to modify /etc themselves.

To be clear: I am entirely sympathetic with the situation you are in. I understand that from a support perspective switching to multi-user only was an absolute necessity, and not by any means a whim.

If I may rephrase the intent of my original post: given that multi-user is now the only option on macOS, can you make me happy about it?

Perhaps a better way to frame the question: let’s ignore macOS. Let’s say I’m on Linux, so I still have both options. Why would I choose the multi-user install on a machine that only has a single user? If it helps, I mostly use Nix as a per-project Nix shell à la direnv / lorri etc.

It’s possible the answer is that multi-user has no benefit to me and it’s just a divergence between my own limited use-cases and the broader goals of the project, but I thought I’d ask rather than assume.

[abathur]

@gaverhae

Is there a place where everything the multi-user installer does is documented in such a way that I can completely undo it and be confident my machine is in the exact same state as if I’d never installed Nix?

Wanted to address this narrowly since it’s a separate but related issue. As best I can tell from the ~issue/PR record, this is a long-oozing wound. It’s gotten a lot better, but it’s also far from ideal.

It depends a little on our standards…

• IMO: no, because there’s no necessarily-complete official source.
• unofficially: I think the gist @toonn has been keeping at Tutorial for installing Nix on macOS · GitHub is “current” as of this post.
• officially: the manual has a section on this (Installing a Binary Distribution - Nix Reference Manual) but it has some clear deficiencies:
  • It doesn’t address cleaning up groups and users at all.
  • Normal doc trouble. I obviously didn’t notice + update that section myself when I updated the macOS section immediately below it…
  • A straightforward list of steps sounds simple, but it gets tricky when multiplied by multiple install conditions evolving over time (not to mention users who do not understand the distinctions). The current information-design doesn’t address ~history, so I imagine it’s prone to problems like either accumulating or having amnesia about old artifacts, and ending up with fuzzy human descriptions of what applies when.

[abathur]

I’d like to make a strong (sharp?) case/point here, but I also want to hedge against it coming off as an attempt to shut down the discussion, so I’ll start by noting that I’m not a decider/gatekeeper here and outline what my “stake” is:

I’m just a bleeding heart for people constantly stepping on rakes around the install/reinstall/uninstall process (read: I burn with frustration at sharp edges in the installer, community indifference to them, and all of the good-will the status quo squanders). I’ve stepped in twice to help with problems the read-only root caused. To do right by people suffering any problems I caused/exacerbated in the process, I’ve generally been checking discourse/GH for installer threads a few times a day since last October.

@gaverhae

What saddens me is the outright removal of single-user as an option.

The background isn’t to short-circuit criticism, but to clarify that I’m commenting as a rando who rolled up my sleeves in a neglected corner of the codebase and don’t feel like I have any authority or perspective to make a call either way.

I made the installer work on macOS in both modes, was a good factotum when reviewers agreed it was too complex, and feel obliged to support my changes until they’ve stabilized.

There is obviously no hard technical reason the installer can’t let you try a single-user install.

I framed my first response around support because I think the important questions are: what would supporting it cost, and who’ll pay those costs? I was hoping you’d see that as an invitation to reflect on what might satisfy you and its likely support burden. I probably I didn’t phrase it open-endedly enough, or didn’t emphasize the right bits?

@abathur

It’s probably obvious enough that you can set up an unsupported configuration, download the installer, comment out the execution guards, and assume responsibility for troubleshooting.
…
my general opinion is that it isn’t a good idea to provide obvious options that will bait some fraction of new users into trying to manually set up and use unsupported configurations.

I see the possibility space as something like:

installer	use directions	mod directions	support
Everyone's free to manually download the installer and comment out the execution guards	modifier	modifier	modifier
Someone's unofficial wrapper downloads the installer and unpacks it for modification	someone / modifier	modifier	modifier
I suspect more people will feel entitled to directions support w/ each step from here.
Undocumented env to DL and unpack for mod	modifier? nix?	modifier? nix?	modifier? nix?
Official wrapper or --option to DL and unpack for mod	Nix site/manual	modifier? nix?	nix? modifier?
Undocumented env to disable guards on --no-daemon	user? nix?	n/a	user? nix?
Documented env/--option to disable guards	nix	n/a	nix / user?
Just remove existing execution guard	nix	n/a	nix

I personally see the last as a bit of a nonstarter, but no point expounding if it’s not even what you have in mind.

[gaverhae]

I think at this point I need to apologize for derailing my own thread. I do not want to debate the installer, or to trigger a change to it. As the title of the post suggests, what I wanted is information on what I, as a user, would gain by choosing a multi-user install (because, as you said, while choosing a single-user install is less convenient than before, it’s definitely still a choice I can make). Let’s all pretend I’m on Linux and I’m asking about the differences so I can make an informed choice.

So far what I got from this thread is:

• There is a risk that some software might try to write inside my Nix store. With a multi-user install, they would not be able to (so would they crash?) whereas with a single-user install they might succeed (and then why is that a problem for me?), though my single-user Nix store is still read-only so they’d have to be determined enough.
• Multi-user is how it works on NixOS, so a multi-user install is closer to what gets most tested and worked on, and thus has more chances of working well overall.

Am I missing anything here?