Nix: inability to resolve some ~wrapped / impure setuid executables such as `sudo`
See original GitHub issueNix has to special-case some setuid executables, and this disrupts resholve’s ability to resolve them to absolute paths. (There are a number of interlocking issues here, and I suspect this will take some time–and some willingness to be squeaky wheels–to get this fixed in Nixpkgs. I vaguely plan to document these issues–but for now I’m just outlining.)
I don’t have a lot of the Nix(OS)/nixpkgs system-level perspective to have the best handle on all of this. I get the impression there isn’t a canonical list, but guessing from the run wrappers on my own NixOS system, this seems like a fair list:
chsh dbus-daemon-launch-helper fusermount3 fusermount kcheckpass kwin_wayland mount newgidmap newgrp newuidmap passwd ping pkexec polkit-agent-helper-1 sg start_kdeinit sudoedit sudo su umount unix_chkpwd
In the near future, I’ll update resholve to raise the following error for a cross-platform subset (ping chsh newgrp passwd su sudo mount umount) of these whenever NIX_BUILD_TOP
is in the environment:
There is not yet a good way to resolve 'sudo' in Nix builds. Your feedback may help me (and the Nix community) understand what the best course of action is here.
See https://github.com/abathur/resholve/issues/29 for info, feedback, and potential workarounds.
In the short term, your best bets for working around this are:
- add a
fake
directive via the CLI or the Nix API. here’s an example of what this would look like forsudo
:- CLI:
--fake 'external:sudo'
- Nix:
fake = { external = [ "sudo" ]; };
- CLI:
- Use resholve’s
prologue
option to inject (at the head of the script) some refinement based on your context:- A run-time check that will abort execution if the lookup fails.
- Add/change the PATH to ensure the lookup will succeed.
- Define a function or alias that executes any specific absolute path you need.
In some more limited cases, you may know that you have access to an executable that doesn’t actually need a setuid wrapper and you really just need resholve to get out of your way. If you’re really sure, you can tell it to back off by adding fix
directive via the CLI or the Nix API. Here’s an example of what this would look like for sudo
:
-
CLI:
--fix 'sudo'
-
Nix:
fix = { sudo = true; };
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (5 by maintainers)
@SamLukeYes the last workaround in the first post may help here. Since 0.8.3 you can use
fix.<command> = true
to bypass the error here and force it to resolve from inputs.(This assumes that you’ve verified that the unwrapped commands will run correctly for the invocations in your script.)
I have a use case this is biting me in. The scripts are running as root already under systemd.
My approach has been to use substitute in place:
and then passing resholve:
but I would prefer to tell resholve that I do want it to resolve these paths even if it is troublesome.
I guess the main reason I prefer it is because I accidentally made a mistake the first time I made this adjustment: I passed an absolute path to
umount
asunmount
and my script broke.