Nix enables Linux build sandboxes by default

A build can name its dependencies and still succeed because an undeclared tool happens to exist on the host. Nix 2.2 makes sandboxed builds the Linux default, reducing that gap between the declaration and the environment available to the builder. The original January 11 release notes describe the default change alongside new checks on output closures.

This matters to the declarative model that attracts me to Nix. A declaration is more useful when the build system can expose a missing dependency immediately. Host software that silently fills the gap makes a successful build less informative about whether another machine can perform the same work.

Sandboxing does not by itself prove that two builds produce identical bytes. It controls part of the environment in which the declared build runs. The distinction matters because dependency isolation and reproducible output answer different questions. Nix 2.2 strengthens the former by making it the ordinary Linux configuration.

The builder sees a restricted filesystem

The configuration manual at the release tag describes a sandbox that exposes the build's store dependencies and temporary build directory instead of the normal host filesystem hierarchy. On Linux it also supplies private versions of several system directories, including proc and dev. Paths explicitly configured through sandbox-paths remain available too.

The manual names undeclared dependencies on files under directories such as /usr/bin as a reason for isolation. A build that invokes a host tool by accident can no longer assume that location contains the normal machine's tools. If the tool belongs to the build, its availability needs to follow the declared environment or an explicit sandbox exception.

Linux builds also use private namespaces for process identifiers, mounts, networking and other system resources. Fixed-output derivations are an explicit exception to the private network namespace, so they can access the network. That exception is important to the actual contract. Calling every sandboxed build completely disconnected would misstate the documented behavior.

The configuration remains adjustable. The release's implementation accepts true, false and relaxed sandbox modes. In relaxed mode, the manual says fixed-output derivations and derivations marked with __noChroot do not run in sandboxes. An enabled default therefore does not eliminate configuration choices or explicit exceptions.

The implementation identifies the platform default

There is a small mismatch in the period documentation. The configuration manual still says the default is false. The release notes announce the Linux change, and the 2.2 settings implementation selects the enabled mode when compiled for Linux. Other platforms take the disabled default in that definition.

That distinction is enough to resolve the specific question about what changed. It does not require assuming that every installation has discarded an explicit existing setting. A release default applies where configuration has not selected another value. The implementation also makes clear that the announcement is Linux-specific.

The filesystem exceptions remain part of the build environment. The manual describes sandbox-paths as bind mounts, with syntax for mounting a source path at another target location. Depending on the build configuration, the defaults can provide a shell through such a mount. Isolation is therefore a defined construction of the builder's environment, not an assertion that no host-provided path can ever appear.

For my use of declarative systems, that explicitness is the useful property. A necessary exception can be represented as configuration. An accidental dependency on whatever is installed elsewhere in the host has no comparable statement of intent.

Output checks constrain what the build retains

Nix 2.2 also adds per-output closure checks for derivations using structured attributes. The release notes explain that setting __structuredAttrs to true passes attributes to the builder in JSON form. The new outputChecks attributes let a derivation state different requirements for its outputs.

The release gives this fragment for an out output.

outputChecks."out" = {
  maxClosureSize = 256 * 1024 * 1024;
  disallowedRequisites = [ stdenv.cc "dev" ];
};

This is a fragment inside the structured derivation described by the release, not a standalone package expression. It limits the out closure to 256 MiB and forbids references to the C compiler or the dev output. The corresponding example for dev limits that output's own size with maxSize.

The difference between maxClosureSize and maxSize is meaningful. A small output can retain dependencies that make its closure much larger. Checking only the output's own bytes does not express a limit on everything it references. Separate checks let the author state whether the concern is the immediate artifact or the dependency set needed with it.

These checks complement sandboxing at another stage. The sandbox constrains available build inputs. Output checks constrain the resulting dependency relationships and sizes. A declared compiler can be necessary during construction while remaining forbidden as a runtime requisite of the main output.

Local builds also enforce machine requirements

The release now enforces requiredSystemFeatures for local builds. Previously that attribute served to route work to remote builders. A machine's supported capabilities are configured with system-features, so the same stated requirement now affects whether the local machine should perform the build.

The notes say kvm is included by default when /dev/kvm exists. They also identify compatibility pseudo-features used in routing Nixpkgs jobs to Hydra machines. Those names are declarations used by scheduling logic, and should not be mistaken for a guarantee that a benchmark or a large build has particular resource isolation.

This is another correction to the relationship between a declaration and actual execution. A requirement should not disappear merely because the selected builder is local. Enforcing it there makes local and remote selection use a more consistent contract.

Installation checks remain a separate tool

The new nix doctor command examines potential installation problems. Its implementation in 2.2 checks matters such as multiple Nix installations in PATH, profile locations and client-store protocol agreement. These are installation checks, not a proof that package outputs are reproducible.

That separation keeps the release's contributions concrete. Doctor helps identify a misconfigured installation, while sandboxing controls builder access and output checks validate selected artifact properties. For a Linux package that previously depended on an undeclared host executable, the changed default makes that dependency visible during the build, where the package expression can be corrected.