builtins.path and builtins.filterSource use wrong filter paths with --store argument

[Yarny0]

Describe the bug

The built-in functions builtins.path or builtins.filterSource both accept a root path and a filter function. The filter function is then called with subpaths of the root path as argument. Under certain circumstances, those subpaths are in fact not subpaths of the root path. As far as I could investigate, this happens if

• the --store argument is used to point to another store that is not the "canonical" store ("canonical" usually is /nix/store),
• the nix file that is evaluate and that contains the call to a built-in function is itself positioned in the "canonical" nix store,
• the root directory points to ./., and
• the derivation that contains the nix file is also present in the other nix store.

Note that these circumstances are usually given when you install NixOS from a live iso with nixos-install: Most nix files involved are contained in the nixos channel, which is somewhere in /nix/store. This channel is copied to /mnt/nix/store by nixos-install before anything else is done.

Steps To Reproduce

Put these two files in the same directory, then execute test.sh (this expects Nix to be installed and accessible, but no root privileges):

test.nix

let
  root = ./.;
  filter = path: type:
    let
      rootStr = builtins.toString ./.;
    in
      if builtins.substring 0 (builtins.stringLength rootStr) (builtins.toString path) == rootStr then true
      else builtins.throw "root path\n${rootStr}\nnot prefix of path\n${builtins.toString path}";
in

# each one will demonstrate the problem!:
#builtins.path { name="name"; path=root; inherit filter; }
builtins.filterSource filter root

test.sh

#! /usr/bin/env bash
tmpdir=$(mktemp -d)
mkdir $tmpdir/directory
cp test.nix $tmpdir/directory/default.nix
result=$(nix-store --add-fixed --recursive sha256 $tmpdir/directory)
nix-instantiate --eval $result
nix-instantiate --eval $result --store $tmpdir/2nd-store
nix-store --add-fixed --recursive sha256 $tmpdir/directory --store $tmpdir/2nd-store
echo this will fail...
nix-instantiate --eval $result --store $tmpdir/2nd-store

The final nix-instantiate will trigger the throw from text.nix -- apparently filterSource confuses the store paths:

error: root path
/nix/store/dv15ix385vx19wxac0v5h5n7x8i5iwgp-directory
not prefix of path
/tmp/tmp.f3xsGxSb42/2nd-store/nix/store/dv15ix385vx19wxac0v5h5n7x8i5iwgp-directory/default.nix

Expected behavior

The final nix-instantiate invocation should succeed.

nix-env --version output

nix-env (Nix) 2.18.5

Additional context

Nixpkgs contains many instances of src = lib.fileset.toSouce { root = ./.; fileset = ..something..; } which are liable to trigger this bug if evaluated from within nixos-install; in that case src ends up as empty directory because the filter function from the fileset library constantly returns false. One such instance is documented (with steps to reproduce with nixos-install) in NixOS/nixpkgs#334098 .

Priorities

Add 👍 to issues you find important.

[infinisil]

Oh this actually sounds related to #9852

[Yarny0]

Hmm, I think I dismissed that because it only occurs within the flake context, while the bug at hand is happening even without flakes. But now that I took a closer look: you're right, the symptoms are quite similar, so it might have the same root cause.

[edolstra]

This is caused by this code in addPath():

        StorePathSet refs;

        if (path.accessor == state.rootFS && state.store->isInStore(path.path.abs())) {
            // FIXME: handle CA derivation outputs (where path needs to
            // be rewritten to the actual output).
            auto rewrites = state.realiseContext(context);
            path = {state.rootFS, CanonPath(state.toRealPath(rewriteStrings(path.path.abs(), rewrites), context))};

            try {
                auto [storePath, subPath] = state.store->toStorePath(path.path.abs());
                // FIXME: we should scanForReferences on the path before adding it
                refs = state.store->queryPathInfo(storePath)->references;
                path = {state.rootFS, CanonPath(state.store->toRealPath(storePath) + subPath)};
            } catch (Error &) { // FIXME: should be InvalidPathError
            }
        }

This is there to handle IFD, where we have to rewrite the "logical" path resulting from the build (i.e. /nix/store/bla) to the physical path (i.e. /prefix/nix/store/bla) that the evaluator can use. But it shouldn't be applied to user-supplied paths.

A possible solution would be for paths resulting from derivations to use an accessor distinct from rootFS.

[ElvishJerricco]

IMO this bug has reached the point of being pretty high severity for Nixpkgs.

• It has caused us to move to ban the really useful filesets library within nixpkgs because of various channel blockers: release: forbid use of lib.fileset in Nixpkgs nixpkgs#369694
  • treewide: post-stc-ng test fixes nixpkgs#340046
  • auto-patchelf: avoid filesets nixpkgs#352491
  • nixos-firewall-tools: don't use filesets nixpkgs#369459
• Even when filesets are avoided, it can still cause different nontrivial and confusing bugs: nixos-option: rewrite as a nix script, 2nd try nixpkgs#369151 (comment)

IMO this bug should be a high priority for the Nix team.

[Mic92]

Will be discussed in the next nix team meeting tomorrow.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2025-01-08-nix-team-meeting-minutes-207/58523/1