Nixpkgs that need --no-sandbox

[wmarais]

I’m trying to add a P4 switch (networking component) package to nixpkgs which only passes unit tests without the sandbox enabled (i.e. nix-build --no-sandbox ....). Is there a way to specify in the default.nix file for the package to build without the sandbox? (Or is there a completely different / better way to fix this?)

[NobbZ]

If you can not make the tests pass because of the sandbox, remove the failing tests, or ignore them, whatever is appropriate in the test framework used.

If its just too many of them disable the checkPhase.

Also, on newer nixes (2.8+) there is is a __* attribute, to disable the sandbox for individual derivations if I recall correctly. Though I do not think those will be accepted into nixpkgs

[wmarais]

Hmm I think I found the attribute: nix.conf - Nix Reference Manual

Just building it now to check if it’s honoured.

I think having to choose between ensuring unit tests pass and disabling the sandbox, I would have to go with the unit tests. Given the components are pretty new and experimental, I think it is critical for the unit tests to be run and pass, otherwise users may be chasing their tails trying to use a broken package.

[NobbZ]

@wmarais

Hmm I think I found the attribute: nix.conf

Nope thats a configuration option.

Though I just checked the most recent release notes, the attribute I had in mind was not about the sandbox but impure derivations:

@edolstra

New experimental feature: impure derivations . These are derivations that can produce a different result every time they’re built. Here is an example:

stdenv.mkDerivation {
  name = "impure";
  __impure = true; # marks this derivation as impure
  buildCommand = "date > $out";
}

Running nix build twice on this expression will build the derivation twice, producing two different content-addressed store paths. Like fixed-output derivations, impure derivations have access to the network. Only fixed-output derivations and impure derivations can depend on an impure derivation.

Nix 2.8.0 released

Hi, I’m pleased to announce the availability of Nix 2.8.0. It will be available from https://nixos.org/download.html. Here are the release notes: New experimental command: nix fmt, which applies a formatter defined by the formatter.<system> flake output to the Nix expressions in a flake. Various Nix commands can now read expressions from standard input using --file -. New experimental builtin function builtins.fetchClosure that copies a closure from a binary cache at evaluation time a…

[wmarais]

You are right. I’ll have a look at the code and see if there is a way to make it work without disabling the sandbox.

[amjoseph]

@wmarais

I think having to choose between ensuring unit tests pass and disabling the sandbox, I would have to go with the unit tests. Given the components are pretty new and experimental, I think it is critical for the unit tests to be run and pass, otherwise users may be chasing their tails trying to use a broken package.

If the package is for your own personal/organizational use then sure, that might be true.

However the sandbox is a critical assumption of nixpkgs’ organizational processes. Reviewers don’t check PRs for “if merged, could the build script inject malware into other build products on Hydra?” If they had to audit for that I think nixpkgs would probably go stale in short order.

@NobbZ

Though I just checked the most recent release notes, the attribute I had in mind was not about the sandbox but impure derivations:

You were probably thinking of the derivation attribute __noChroot (follow @wmarais’s link and scroll down further).

<rant>
I find the terminology around nix’s sandbox to be maddeningly inconsistent. In some places it is called the “sandbox”, in other places it is called “chroot”. And then there is “syscall filtering” which nix treats as being totally orthogonal to the sandbox, but without which you can defeat the sandbox, so it’s clearly part of sandboxing but not part of “the sandbox”. Argh. I am glad I’m not in a situation where I have to explain this to customers/management/higher-ups, although since it’s security-critical I have to assume that other people are in that situation.

@wmarais

You are right. I’ll have a look at the code and see if there is a way to make it work without disabling the sandbox.

You’re in for a treat.

When I dug into the nix source code a while back I discovered that “the sandbox is enabled” isn’t all or nothing, there are various levels of sandboxing that are enabled or disabled based on which Linux APIs (namespaces, ptraces, etc) nix was succesful in invoking. Sometimes some of those will fail and nix will silently proceed with only partial sandboxing.
</rant>

[wmarais]

Thanks @amjoseph. Ha! I was wondering what the difference was, if any, between sandbox and chroot in nix, did not even know about the syscall filtering, but it makes sense.

I did not mean the nix source, I meant the package source that I am trying to build (its, not my code). Though, I think I will probably just do something along the lines of what @NobbZ suggested and disable those unit tests. (Specifically, I am thinking of writing a bit of script to detect if it’s being compiled in the sandbox, and if so then disable the tests, and if not enable the tests. That way I can still configure my nixos install to disable sandboxing for those systems without angering Hydra.)

[amjoseph]

@wmarais

I am thinking of writing a bit of script to detect if it’s being compiled in the sandbox

Your best bet here is to examine /bin/sh. The sandbox has to redirect that in order to implement POSIX’s system(3). For example:

with import /nix/nixpkgs { };
stdenv.mkDerivation {
  name = "demo";
  dontUnpack = true;
  nativeBuildDependencies = [ pkgs.coreutils ];
  buildPhase = ''
  ${pkgs.coreutils}/bin/md5sum /bin/sh
  '';
  dontInstall = true;
}

Put the above in demo.nix and try

nix-build demo.nix --option sandbox false
nix-build demo.nix --option sandbox true

You’ll get different hashes.