Documentation should point out that impure and noChroot do not affect builtins in the way that --impure does #390

New issue

Open

opened 2024-06-11 07:07:09 +00:00 by irenes · 4 comments

irenes commented

2024-06-11 07:07:09 +00:00

Owner

Problem

There are several related concepts of pure evaluation, sandboxing, etc. Flakes introduce a concept of pure evaluation which restricts the behavior of certain builtins, including builtins.readFile, and removes others. The nix "sandboxing" option introduces a different behavior, which among other things does builds in a chroot when it's true, and also prevents network access.

The --impure flag, given at the command line, disables both of these behaviors. By design, it must be given every time, it cannot be set system-wide. This is probably a good thing.

There are at least two special-purpose attributes, one of them experimental, which override some of this behavior on a per-derivation basis. __impure allows network access, regardless of the setting of the sandboxing option. __noChroot causes the derivation to be built without a chroot, but only when the sandboxing option is set to the non-default value "relaxed". Neither of these attributes does anything to allow unrestricted use of builtins, and indeed due to lazy evaluation semantics it's not clear how that could happen on a per-derivation basis. This is unfortunate for use-cases that really need to not only access the filesystem but use that information in nix evaluation, but the restrictions make sense once properly understood. What doesn't make sense is the documentation.

Proposal

I realize that __impure is an experimental feature (the others are mainline), but this complex tangle of behaviors is quite difficult to make sense of. I think it would be useful to have some sort of "escape hatches" section of the manual which describes it all in one place.

Checklist

checked latest Nix manual (source)
checked open documentation issues and pull requests for possible duplicates

## Problem There are several related concepts of pure evaluation, sandboxing, etc. Flakes introduce a concept of pure evaluation which restricts the behavior of certain builtins, including builtins.readFile, and removes others. The nix "sandboxing" option introduces a different behavior, which among other things does builds in a chroot when it's true, and also prevents network access. The --impure flag, given at the command line, disables both of these behaviors. By design, it must be given every time, it cannot be set system-wide. This is probably a good thing. There are at least two special-purpose attributes, one of them experimental, which override some of this behavior on a per-derivation basis. __impure allows network access, regardless of the setting of the sandboxing option. __noChroot causes the derivation to be built without a chroot, but only when the sandboxing option is set to the non-default value "relaxed". Neither of these attributes does anything to allow unrestricted use of builtins, and indeed due to lazy evaluation semantics it's not clear how that could happen on a per-derivation basis. This is unfortunate for use-cases that really need to not only access the filesystem but use that information in nix evaluation, but the restrictions make sense once properly understood. What doesn't make sense is the documentation. ## Proposal I realize that __impure is an experimental feature (the others are mainline), but this complex tangle of behaviors is quite difficult to make sense of. I think it would be useful to have some sort of "escape hatches" section of the manual which describes it all in one place. ## Checklist  - [ ] checked [latest Nix manual] \([source]) - [ ] checked [open documentation issues and pull requests] for possible duplicates [latest Nix manual]: https://nixos.org/manual/nix/unstable/ [source]: https://github.com/NixOS/nix/tree/master/doc/manual/src [open documentation issues and pull requests]: https://github.com/NixOS/nix/labels/documentation

jade commented

2024-06-11 08:32:46 +00:00

Owner

The --impure flag, given at the command line, disables both of these behaviors. By design, it must be given every time, it cannot be set system-wide. This is probably a good thing.

--impure affects only the evaluator. It has no effect on the sandbox or the builder whatsoever.

> The --impure flag, given at the command line, disables both of these behaviors. By design, it must be given every time, it cannot be set system-wide. This is probably a good thing. --impure affects only the evaluator. It has no effect on the sandbox or the builder whatsoever.

irenes commented

2024-06-11 19:10:06 +00:00

Author

Owner

That doesn't seem consistent with the tests I did last night, but it's possible that I wasn't testing in a way that drew out the actual behavior. At any rate I think there's more than enough potential for confusion that this needs documentation, heh.

jade commented

2024-06-11 20:01:34 +00:00

Owner

I have confirmed in the code. b8cb7abcf0/src/libcmd/common-eval-args.cc (L113-L120)

I have confirmed in the code. https://git.lix.systems/lix-project/lix/src/b8cb7abcf08be01a291c970164a3f44dfca0ddbf/src/libcmd/common-eval-args.cc#L113-L120

irenes commented

2024-06-11 20:37:16 +00:00

Author

Owner

Huh. Thank you. I think I understand how my test case wound up not hitting that... I had a lot of trouble at first separating out the builtin semantics from the chroot, since they both restrict the filesystem.