"/var is a symlink" error on macOS when using nix-env -iA under root

[ink-splatters]

Describe the bug

if legacy profile is configured under root user, packages installation fails because of new check for symlinks

Steps To Reproduce

airstation:~ sudo -I

airstation:~ root# nix-env -iA nixpkgs.bashInteractive
error: path '/var' is a symlink

nix-env --version output

nix (Nix) 2.20.3

Additional context

It looks like an implemented feature (please see below), which makes me a bit worried: the use case might be really rare, but in my likely unpopular configuration (installing globals under root, because In Sandbox We Trust!:) this resulted in enrolling in to flakes, which I'm fine with when I need it and not when I'm forced to.

Why I mentioned this: I can anticipate that the affected scenario is not priority for the team as / if it concerns the minority of users, which is fair reason to postpone it or close with WONT FIX.

These are my 2 cents in order for my voice to be heard: I'd rather like this to be fixed :)

I actually could have submitted a PR instead of an issue, but I guess this is about a choice made and if this choice is immutable, or on the contrary - it's just merely a bug and the installs like mine take place around.

airstation:nix ic$ rg "is a symlink\""
src/libutil/posix-source-accessor.cc
106:            throw Error("path '%s' is a symlink", showPath(path));
airstation:nix ic$ git blame src/libutil/posix-source-accessor.cc | rg  "is a symlink\"" -B 10
83c067c0fa (Eelco Dolstra 2023-12-05 23:02:59 +0100  96) void PosixSourceAccessor::assertNoSymlinks(CanonPath path)
83c067c0fa (Eelco Dolstra 2023-12-05 23:02:59 +0100  97) {
83c067c0fa (Eelco Dolstra 2023-12-05 23:02:59 +0100  98)     // FIXME: cache this since it potentially causes a lot of lstat calls.
83c067c0fa (Eelco Dolstra 2023-12-05 23:02:59 +0100  99)     while (!path.isRoot()) {
83c067c0fa (Eelco Dolstra 2023-12-05 23:02:59 +0100 100)         struct stat st;
83c067c0fa (Eelco Dolstra 2023-12-05 23:02:59 +0100 101)         if (::lstat(path.c_str(), &st)) {
83c067c0fa (Eelco Dolstra 2023-12-05 23:02:59 +0100 102)             if (errno != ENOENT)
83c067c0fa (Eelco Dolstra 2023-12-05 23:02:59 +0100 103)                 throw SysError("getting status of '%s'", showPath(path));
83c067c0fa (Eelco Dolstra 2023-12-05 23:02:59 +0100 104)         }
83c067c0fa (Eelco Dolstra 2023-12-05 23:02:59 +0100 105)         if (S_ISLNK(st.st_mode))
83c067c0fa (Eelco Dolstra 2023-12-05 23:02:59 +0100 106)             throw Error("path '%s' is a symlink", showPath(path));
airstation:nix ic$

[domenkozar]

@edolstra I've seen a similar error on NixOS when using --impure with flakes: error: path '/home/domen/.nix-defexpr/channels' is a symlink

[jaysonsantos]

The same happens on nix-env (Nix) 2.20.5 also on macs and, upgrade it not possible anymore.

sudo nix-env --upgrade
warning: $HOME ('/Users/jayson.reis') is not owned by you, falling back to the one defined in the 'passwd' file ('/var/root')
error: path '/var' is a symlink

[ink-splatters]

The same happens on nix-env (Nix) 2.20.5 also on macs and, upgrade it not possible anymore.

sudo nix-env --upgrade
warning: $HOME ('/Users/jayson.reis') is not owned by you, falling back to the one defined in the 'passwd' file ('/var/root')
error: path '/var' is a symlink

I guess @edolstra (see the blame log above) would be the best person to get a comment from, once they are able to answer, and it also looks like a feature.

The thing is: /var on macOS is a firmlink, so e.g. removing it and using the same /etc/firmlinks facility, which is used for /nix, will require Permissive Security¹

---

¹ at least until someone has figured out how to properly re-seal System volume, mimicking the behaviour of Apple restore and update ramdisks which use apfs_sealvolume ( present in Recovery ramdisk as well).

I had partial success with it, being able to create sealed snapshot with properly matched root_hash (easy because the sealer leaks correct hash in its error message) and convert it to required im4p format.

However macOS (unsurprisingly) refused to boot, bawling at me with accusations of sticking my nose too far into not my business. Fair enough.

At this point, it also starts looking more like an adult hackery: reversing SEP mailbox API and APFS volume personalisation (creating and/or signing APFS keybags using known TSS protocol) might be ways to go.

On the other hand, tampering with APFS itself, e.g. creating a firmlink by writing raw bytes to APFS media at proper offset, is quite straightforward, thanks to:

• awesome J.T. Sylve APFS Advent challenge, documented
• and less awesome but still decent official APFS reference (mind PDF format)

Both contain C struct decls, so having got a grasp on it, one can get away with dd xxd and maybe bc (for scripting fletcher64 checksums). Which may be sort of fun, depending on personal preferences :)

[nixos-discourse]

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

https://discourse.nixos.org/t/switch-cache-nixos-org-to-zstd-to-fix-slow-nixos-updates-nix-downloads/23961/47

[fricklerhandwerk]

Triaged in Nix team meeting:

• @roberth we have SourceAccessors which don't have symlink logic (this is enforced in the commit)
• @edolstra: will take a look

[nixos-discourse]

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

https://discourse.nixos.org/t/error-path-home-is-a-symlink/42267/4

[ink-splatters]

Triaged in Nix team meeting:

• @roberth we have SourceAccessors which don't have symlink logic (this is enforced in the commit)

Is it something being looked at, already; and if yes, may I wonder what the branch is?

[nixos-discourse]

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

https://discourse.nixos.org/t/2023-03-27-nix-team-meeting-134/42961/1

[edolstra]

@ink-splatters This is supposed to be fixed in 2.20.6.

[jaysonsantos]

@edolstra is there a tutorial on how to upgrade it when it is on a broken state?

[johbo]

@jaysonsantos I just did bump into this on my machine, I got it handled by using nix-shell -p nixUnstable which gave me a shell with an updated nix, there I was able to run the update command.

Not sure though if that's a sane approach, hope this might help you get going again.

[ink-splatters]

@jaysonsantos below is how I fixed it by installing from scratch

kudos @edolstra (ik bedoel, Dankjewel!!!) and other guys at Determinate Systems:

I have just tried new nix-installer which has become much more mature, verbose if I want it to be, and eventually worked like a charm! ❤️

NOTE: NIX_INSTALLER_NIX_PACKAGE_URL is needed because the bundled nix version is too old

You will want at least 2.20.6 (according to #10247 (comment))

I chose the last tagged one: 2.21.2

installation

NOTE: This is a recipe for clean install!

I disrooted old nix remains before proceeding, if you're feeling opportunistic enough to proceed from unclean state - your miles may vary

NOTE: Fix your arch/version accordingly, if on Linux

NOTE: running by unprivileged user will ask for root. I didn't check if the env is passed by installer, so I rooted me myself

sudo -i
cd /tmp

curl -sL -o nix-installer https://install.determinate.systems/nix/nix-installer-aarch-64-darwin
chmod +x ./nix-installer

export NIX_INSTALLER_NIX_PACKAGE_URL=https://releases.nixos.org/nix/nix-2.21.2/nix-2.21.2-aarch64-darwin.tar.xz

./nix-installer

assuming nix now works:

nix-channel --update

🪄✨

[edolstra]

@ink-splatters Thanks, will close the issue!