In theory it is safe. When a Nix package is built it isn’t “installed”. Unless root is running/installing random packages out of the Nix store there is no problem. As long as the user’s aren’t added to the trusted-users option they shouldn’t be able to cause any problems for other users.

However like any multi-user system you are sharing a Linux kernel. A kernel is a very complex piece of software with a huge attack surface. Privileged escalation vulnerabilities are commonly found. (This also applies to the nix-daemon, but it is a bit smaller attack surface but vulnerabilities are still occasionally found.) So you shouldn’t assume strong security isolation. I would say that a setup like this is acceptable for mostly-trusted people like coworkers or friends that are not expected to actively exploit vulnerabilities but definitely wouldn’t let random unknown users use the system.

So if you want strong isolation use a VM or separate hardware, but then you won’t be able to share the builds and packages defeating the point in this case.

If you mean Nix, the package manager, then no packages are actually installed as root. Every package is installed in the Nix store, but programs that need root privileges can’t be run by any user.

One of the (many) great things about Nix is that users don’t need root privileges to install packages.

Assuming you’re talking about Nix the package manager,

Nothing is actually “installed as root”, except for stuff that the root user installs themselves. The Nix Store (where all the “derivations”/packages are stored) can be thought of more as a cache, just because a package is there doesn’t mean it’s used anywhere. Users don’t get to choose the cache “key” (i.e. the directory name in /nix/store) either - it is determined by all the build instructions and dependencies needed to build the package, and Nix doesn’t (well, at the very least shouldn’t) give users any control about the package build process after it starts.

When users install something, Nix fetches or builds that package into /nix/store - which doesn’t affect other users in any way - and then just symlinks that particular package into some user-owned directory in their $PATH (e.g. $HOME/.local/share/nix/profiles/default or so), which also doesn’t affect root or other users in any way.

So, basically, if some user installs malware only they are affected - the fact that it’s also in the shared /nix/store is irrelevant since there’s nothing in other user’s profiles or $PATH or whatever that references it in any way.

The most likely vulnerability is something like this:

1. The attacker guesses the nix store path of some package that root will use in the future (e.g. glibc from a more up-to-date Nixpkgs version compared to what root currently uses) - note that users can’t replace a derivation that’s already in the store, so they need to guess a future derivation path
2. The attacker forces Nix to build that package from source instead of fetching from a trusted substituter
3. The attacker finds a way to breach Nix’s sandbox during the build and inject their own backdoor into the resulting package ← this is the difficult part, there are currently no such known sandbox holes
4. The attacker then waits until root starts using that package in the store, at which point the backdoor becomes actively ran as root.

I must add that this is theoretical and I don’t think has ever happened in practice on a multi-user system.

Sorry, I’m pretty bad at explaining stuff, hopefully it makes some sense :)

Are you talking about NixOS?

You can install post user nix home manager distributions which are separate from the shared nix environment (not sure if that’s the right term)

Do you want explain a bit more?

Linux is Linux. If you’re using the standard install packages like Pam, then it’s built specifically for multiple users.

Elaborate more if you could.