Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nix: inability to resolve some ~wrapped / impure setuid executables such as sudo #29

Open
abathur opened this issue May 28, 2021 · 8 comments
Labels
bug Something isn't working feedback wanted Looking for user input. help wanted Extra attention is needed

Comments

@abathur
Copy link
Owner

abathur commented May 28, 2021

Nix 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:

  1. add a fake directive via the CLI or the Nix API. here's an example of what this would look like for sudo:
    • CLI: --fake 'external:sudo'
    • Nix:
      fake = {
        external = [ "sudo" ];
      };
  2. 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;
    };
@abathur abathur added bug Something isn't working help wanted Extra attention is needed feedback wanted Looking for user input. labels May 28, 2021
@grahamc
Copy link
Contributor

grahamc commented Dec 10, 2021

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:

  (substituteAll {
    ...
    mount = "${util-linux}/bin/mount";
    umount = "${util-linux}/bin/umount";
  })
for mountloc in $(@mount@ \
   ...
   @umount@ "$mountloc" || true
done

and then passing resholve:

keep = [
    "${util-linux}/bin/mount"
    "${util-linux}/bin/umount"
  ];

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 as unmount and my script broke.

@dbaynard
Copy link

msmtpq is broken because of ping (see NixOS/nixpkgs#195532). The approach here doesn't appear to work.

I'd be grateful for some help — perhaps the resolution could then be added to the documentation?

@abathur
Copy link
Owner Author

abathur commented Nov 28, 2022

@dbaynard Just in case you're watching here but not there, I reached out to what I assume is your handle on Matrix earlier this evening.

@SamLukeYes
Copy link

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:

  (substituteAll {
    ...
    mount = "${util-linux}/bin/mount";
    umount = "${util-linux}/bin/umount";
  })
for mountloc in $(@mount@ \
   ...
   @umount@ "$mountloc" || true
done

and then passing resholve:

keep = [
    "${util-linux}/bin/mount"
    "${util-linux}/bin/umount"
  ];

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 as unmount and my script broke.

There's a similar case in arch-install-scripts. When using NixOS's setuid wrappers, its unshare mode doesn't work (https://github.com/archlinux/arch-install-scripts/issues/38). I think simply resolving mount/umount would fix it.

@abathur
Copy link
Owner Author

abathur commented Dec 18, 2022

@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.)

@Jayman2000
Copy link
Contributor

It looks like systemd is adding a new sudo replacement named run0 that doesn’t use setuid. I bet that you could workaround this problem by using run0 instead of sudo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working feedback wanted Looking for user input. help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

5 participants