darwin-rebuild: Don't prompt for sudo multiple times

[kabiroberai]

I've found that darwin-rebuild switch always asks me for sudo permissions twice — once when it runs sudo nix-env --set and the second time when it runs sudo $systemConfig/activate — even though I have a reasonable (default) timestamp_timeout.

In debugging this, I realized that the call to brew bundle within activate-user was somehow making it so that the next sudo invocation would require a password again. I'm honestly not sure of the root cause behind this strange behavior exhibited by brew bundle, but as a workaround I realized that if we 1) elevate privileges, 2) drop down to call activate-user, and 3) call activate in the elevated context, we don't need to sudo again since we're already root.

FWIW I'm open to input here, especially as a new nix-darwin user: is this issue specific to me or is everyone just used to authenticating twice? Do let me know if I'm "holding it wrong". But Brew Bundle aside, this PR does work around the general issue where arbitrary user scripts in activate-user can result in sudo prompting again, so I think this might be worth merging regardless of the root cause.

[Enzime]

LGTM

@emilazy any thoughts on this PR?

[emilazy]

I don’t suppose brew bundle is perhaps taking a long time for you (say, over the default 5 minute sudo timeout)?

My thoughts:

1. This drops the env from the sudo call, which seems probably unintentional and could be bad.
2. Most users with the default sudo timeout don’t seem to experience being prompted multiple times, or I’d expect to have heard about it sooner.
3. For users with a zero‐second sudo timeout (like me), the profile switch + activation dance will be two prompts even after this PR.
4. Given (2) and (3), this seems like it’s just working around some specific peculiarity of your setup. That’s not inherently a problem, of course, but it’d be good to understand what’s going on here – e.g. perhaps Homebrew is installing something that invokes sudo in such a way as to clear the grace period? But that doesn’t explain why it’d be happening all the time…
5. However, in this case, fixing that peculiarity is changing the activation environment slightly in a way that I don’t think should break anything but feel hard to be fully confident about.
6. And, after Nixpkgs 24.11 is released – so, in a month or two – I plan to finally deprecate the concept of a user activation phase entirely, per The Plan™. This would mean that everyone would consistently only get one sudo prompt, because activation would be done with sudo darwin-rebuild switch, like NixOS. The good news is that this will result in an activation environment more like this PR anyway. The bad news is that I think the backwards‐compatibility logic to accommodate this change would become slightly more complicated.

(1) is the only blocker here for me, but the factors combined make me wonder if it’s worth doing this right now. It’d be good to understand what’s causing this better, since it seems like most people don’t experience this problem – would you perhaps be able to share your nix-darwin configuration, or at least the Homebrew portion of it?

[kabiroberai]

So I just did some more digging and discovered that this is a "feature" of homebrew, introduced in Homebrew/brew#17694. Current source here: https://github.com/Homebrew/brew/blob/451c3a8735eb9b3050e40802a771eddf7c23e568/bin/brew#L72

I've boiled it down to this MRE:

sudo ls # asks for password
brew --help
sudo ls # asks again!

I'm not entirely sure I understand the rationale but orthogonally this makes me wonder whether we should implement something similar in darwin-rebuild, resetting the sudo timestamp after activation. This appears to have been a fix for a formula privilege escalation vulnerability that was found in a security audit. See page 35 of this document. Don't think it's necessary to implement anything similar in nix-darwin because the threat model is pretty different.

@emilazy responding to some of your other points:

1: Dropping the env was indeed an oversight on my part, can fix that. On a related note, do we want to use command sudo or /usr/bin/sudo? I switched to an absolute path since I figured it's more deterministic but let me know if there's a reason we use command here.

2: Going by the fact that this is in the brew driver, perhaps other people have run into this and simply haven't reported it? Might be worth asking a few folks?

3: In that case could we go a step further and do the elevate/drop dance at the point where we first invoke sudo? I recognize this would make it easier to violate the principle of least privilege without extra care — but indeed going by point 6 it sounds like this is already the intended direction.

6: It's good to hear that! I recall instinctively trying sudo darwin-rebuild at first and running into errors that made me slightly concerned that I'd broken something. Handling elevated privileges correctly also seems very exciting because it enables creating something like a launch daemon that calls darwin-rebuild — perhaps driven by a GUI app, properly validating the XPC audit token to be sure — without needing to reauthenticate. can't wait to unpack that LPE-shaped can of worms lmao

Let me know if you still want more details about my configuration — or whether you're able to repro the MRE ootb.

[emilazy]

Re (1), I think I would prefer command sudo because maybe the user installed their own sudo and wants to use it (though that’s not really possible to do through nix-darwin at present). (2) is indeed puzzling – I’m no longer so puzzled by this behaviour now that I know Homebrew is intentionally doing it, but the Homebrew module is popular and this is definitely the kind of thing I’d expect to get reports about, but maybe people aren’t too fussy for once! I once tried to make (3) happen but if you trace out the logic of the script it’s pretty awkward to get the profile‐switching sudo to be the same as the activation sudo – sufficiently awkward that I decided to just wait to do away with the idea of running darwin-rebuild as a non‐privileged user entirely, like my similar inclination for this PR.

Moving more stuff from activation scripts into launchd daemons, in line with NixOS’s trajectory, is definitely a goal. We technically do already have a system activation daemon that runs as boot, but it barely activates anything… (see #726). Activation changes will also make it easier for us to support multi‐user setups and to mostly reuse existing NixOS deployment tools, which is pretty exciting, and part of the reason I’m hesitant to introduce more activation complexity that we’d have to preserve for a while for backwards compatibility.

[khaneliman]

Re (1), I think I would prefer command sudo because maybe the user installed their own sudo and wants to use it (though that’s not really possible to do through nix-darwin at present). (2) is indeed puzzling – I’m no longer so puzzled by this behaviour now that I know Homebrew is intentionally doing it, but the Homebrew module is popular and this is definitely the kind of thing I’d expect to get reports about, but maybe people aren’t too fussy for once!

I've seen this behavior for a long time, but never bothered reporting it or looking into it :P Mainly because i just need to move my finger a few inches, but it is kinda annoying if I want to kick off a rebuild and walk away.

[z0al]

Most users with the default sudo timeout don’t seem to experience being prompted multiple times, or I’d expect to have heard about it sooner.

For what it's worth, this also happens to me, but I didn't care enough to report it. My sudo timeout is 30 minutes.

The issue started a few months ago around the time the change to restart the dock on activation is introduced if I remember correctly

Edit: somehow after writing my comment I realized that the double sudo prompt doesn't happen anymore for me recently. However, I still get promoted for sudo once even when my sudo session hasn't expired.

[adamjhf]

I also get prompted for password ~3 times for darwin-rebuild with Homebrew and sudo timeout, across multiple machines. I've temporarily removed Homebrew to avoid this.