| 26 May 2021 |
LnL | but it's not a __impureHostDep, it's a runtime dependency so I don't get why you need this | 20:07:39 |
LnL | it's the same on linux, you can't use pkgs.sudo at runtime you need the setuid wrapper which is available through PATH | 20:09:11 |
abathur | hmm, that may sink it | 20:11:36 |
abathur | I noticed that it works on Linux, though I haven't looked into how | 20:12:00 |
abathur | anyways; resholve's point/goal is nailing everything down at build time (and blocking if it can't), so the problem/need is unaffected by the suitability of the solution | 20:14:08 |
LnL | sudo is a tricky one for that, since even on linux it can be either /run/wrappers/bin/sudo or /usr/bin/sudo | 20:16:09 |
LnL | unless nix gets some kind of native support for setuid binaries | 20:16:35 |
LnL | same with eg. ping by the way | 20:18:18 |
abathur | edited the post to reframe it around what resholve needs wrt to the broader problem I guess | 21:18:04 |
ris_ | one thing about the sandbox on darwin - i don't find i can disable it case by case on the command line even though i've set nix.trustedUsers = [ "*" ]; | 22:58:52 |
| aaronjanse joined the room. | 23:13:30 |
| 27 May 2021 |
abathur | LnL: is there an authoritative list? is it fair to take /run/wrappers/bin on NixOS as such? | 00:02:24 |
emily | there's no reason nix-darwin couldn't support /run/wrappers for compatibility right? | 00:22:07 |
emily | it already shoves /run into the hierarchy, might as well make use of it | 00:22:20 |
abathur | it could, and that'd be an improvement, but I suspect it won't fix my core issue; the paths would still be invalid on macOS without nix-darwin, and probably on all other non-nixOS linuxes? | 00:26:25 |
abathur | and it's not just the lack of a ~well-known path, I guess, it's also somewhat about mental models and clarity? | 00:27:55 |
abathur | like, ideally, resholve will rebuff you if you pass it any shell script that invokes anything that doesn't resolve to a keyword, builtin, alias, or function | 00:28:26 |
abathur | and the way to satisfy it is to explicitly pass your inputs | 00:28:44 |
abathur | sorry; interrupted; so a magic hardcoded path for sudo (and probably some others) on Nix* is already a bit meh (not that I wouldn't make the pragmatic compromise...); it breaks the explicitness model and leaves the user with undeclared dependencies | 00:49:18 |
abathur | and if resholve's just trusting a magic path that isn't reachable from the build sandbox, it'll also mean disabling the check that the target exists and is executable, so it won't be able to successfully block on any cases where it doesn't :[ | 00:51:57 |
emily | In reply to @abathur:matrix.org it could, and that'd be an improvement, but I suspect it won't fix my core issue; the paths would still be invalid on macOS without nix-darwin, and probably on all other non-nixOS linuxes? yeah, this is a problem not quite unique to sudo though :( | 01:12:08 |
emily | if you grep /run/current-system/sw/bin in nixpkgs you can find a decent amount of hardcoding | 01:12:18 |
emily | stuff that depends on system functionality ultimately ends up system-dependent | 01:12:33 |
emily | In reply to @abathur:matrix.org like, ideally, resholve will rebuff you if you pass it any shell script that invokes anything that doesn't resolve to a keyword, builtin, alias, or function I think the correct thing is to consider "sudo" part of the ABI between shell script and system | 01:13:11 |
emily | it's correct to rely on $PATH when the thing you specifically want is late-binding of the sudo belonging to the current execution environment | 01:13:27 |
emily | so you should be able to tell resholve "treat sudo as system interface glue and allow it to pass through as if it's a built-in", say? | 01:13:46 |
emily | It's like how on macOS, our binaries aren't statically linked, they contain late-bound references to all the libSystem stuff | 01:14:15 |
emily | "where the sudo binary is" is part of the runtime system interface | 01:14:29 |
abathur | I'm not quite sure on the PATH part | 01:58:25 |
abathur | I'm not strictly opposed to treating it that way, but it is a violation of resholve's ~model and the promise it is trying to make; if it came down to that I'd be inclined to kick the can until enough actual resholve users exist to reach consensus about which behavior is right for their uses | 02:01:18 |