Conversation
Elevation programs without cached authorization otherwise prompt once for every privileged switch step.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (6)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe PR adds ChangesSingle-elevation switch
Suggested reviewers: Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to This change adds an opt-in single-elevation mode for local NixOS switches that consolidates repeated authorization prompts into one privileged re-execution, while preserving the existing remote and non-single-elevation behavior. Inspection of the new privileged execution path found the expected safeguards in place (an independent root check in the elevated child, and normal dry-run handling before any elevation occurs), so this looks safe to merge as an opt-in feature. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 38.89% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 18 functions across 4 files. (2 skipped: 2 unsupported.)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
| programs.nh = { | ||
| enable = true; | ||
| clean.enable = true; | ||
| enable = true; |
There was a problem hiding this comment.
You seem to have forgotten to add this option to the NixOS module. Do you intend for this to be nixpkgs-module exclusive?
There was a problem hiding this comment.
oops, I didn't even realise you'd nuked this repo's module and I guess I just skipped over it, lol
| #[arg(long, env = "NH_SINGLE_ELEVATION", value_parser = clap::builder::BoolishValueParser::new())] | ||
| pub single_elevation: bool, | ||
|
|
||
| #[arg(long)] | ||
| pub no_single_elevation: bool, |
There was a problem hiding this comment.
Why would we use both of these? I assume we can just do --single-elevation=false if we want to disable single-command elevation?
There was a problem hiding this comment.
makes sense, the main reason is giving an escape hatch to people who set single elevation in their system and want a one-off, but just making it an on-by-default boolean is probably better
| fn forwarded_verbosity_args( | ||
| args: impl IntoIterator<Item = OsString>, | ||
| ) -> Vec<OsString> { | ||
| args | ||
| .into_iter() | ||
| .take_while(|arg| arg != "--") | ||
| .filter(|arg| { | ||
| arg.to_str().is_some_and(|arg| { | ||
| matches!(arg, "--verbose" | "--quiet") | ||
| || arg.strip_prefix('-').is_some_and(|short| { | ||
| !short.is_empty() | ||
| && short.chars().all(|flag| matches!(flag, 'v' | 'q')) | ||
| }) | ||
| }) | ||
| }) | ||
| .collect() | ||
| } |
|
thank you both for the review - before I take any further action to rectify these issues, @faukah has mentioned that you'd consider making single elevation the default strategy. what do you think, @NotAShelf ? I'd be happy enough to expand the scope here if it's desired, or I can just patch up and follow @faukah's suggestion up in later work. |
Fine by me. |
this PR enables "single elevation", ie. a full switch to be performed in a single child process.
this benefits run0 users and others without persistent/cached authorisation in their environment.
it is used with the
--single-elevationflag, or theNH_SINGLE_ELEVATIONvariable (which can be set by a module option).exclusion is achieved with
--no-single-elevationin the case of the variable being present but the user desiring a one-off non-single-elevation switch.it is achieved by the nh process re-executing itself privileged using a hidden argument, with the elevated child performing all necessary actions for the switch.
presently, it only effects the
switchcommand, although could be extended to others if desired.in order to make this feasible without bloating function signatures, it also flattens the
elevate/ElevationStrategybool/enum pair to anOption<ElevationStrategy>, with the matching semantics you'd expect.Sanity Checking
nix fmtto format my Nix codecargo fmtto format my Rust codecargo clippyand fixed any new linter warnings.logic
description.
x86_64-linuxaarch64-linuxaarch64-darwinAdd a 👍 reaction to pull requests you find important.