Thank you for the report. I've started looking in to the issue and am working with the NixOS security team on getting this addressed.

This is still incomplete. The permissions of /nix/var/nix/profiles/$USER also need to be 755 or less, and enforced as such. Without that enforcement, users can still modify other users profiles right underneath them.

This is especially true in environments where all users share the same primary group.

@edolstra Please don't release until this is fixed.

Looks like we missed the release window sadly.

I think a better fix is to either

• Change permission on .../per-user to 755. Subdirectories can then be created via useradd hooks.

• (Better) Move the per-user profiles to the user's home directory. (Idem for gcroots/per-user)

The useradd approach is a little inconvenient; in practice the subdirectories would still need to be created on first login, since in large multi-user deployments you don't want to create profile directories for every user on every host; there might be tens of thousands of users.

Moving the per-user profiles to the user's home directory sounds good, but it would be a loss of capability compared to current Nix: Currently you can run nix-daemon unprivileged on systems with arbitrary setups and it mostly works. If the per-user profiles were in the user's home directory, the nix-daemon would either need to be root or the user's home directories would need to be globally traversable (have 001 set) so that the nix-daemon could find the roots.

Also, if we moved the per-user profiles to the user's home directory by just making a symlink to that directory, we'd still need to do checks on the ownership and mode of the symlink.

@catern

I think garbage collection already has to traverse home directories for indirect roots.

If you have a multi-user system with non-privileged Nix daemon, you can allow access with setfacl, or you could allow group traversal and set the home directories to a group that includes only a user for Nix daemon.

I am less of a fan of moving these into user home directories, it also makes auditing harder.

Again on systems that can have thousands of users on them, via LDAP or otherwise, only a handful are likely logging into any given machine. To figure out nix usage right now is fairly trivial, you can just look at /nix/var/nix/profiles/ and gcroots and understand who is using nix, and what they have.

With this change, nix will likely have to enumerate all users, and then scan them, and similar behavior will have to be done to audit usage.

Further more, it may be challenging to enumerate all users. SSSD has an option to disable it, which may be desirable for performance reasons. All attempts to get a full list of users that might run on the machine will only return entries in the local /etc/passwd file. SSSD plans to fully remove enumeration in their next major release.

At the very least, if this is ultimately decided to move into home directories, a symlink in /nix/var/nix/gcroots/$USER to the new location would be required to ensure backwards comparability. As long as the new code uses these symlinks for identifying where to look for profiles and roots, this would also not break systems where enumeration is disabled.

The only advantage we then gain over what we have today is that people can't use /nix/var/nix/profiles/ as a persistent world writable space.

However because of backwards compatibility, all the checks @catern is suggesting would still be required.

Bumping this, has any decisions or progress been made on closing this hole?

@edolstra thoughts on this?

We still need to fix this.