Repository navigation
Make it possible to run the Nix daemon as a non-root user #5208
Description
Problem
In multi-user mode, Nix currently assumes that the daemon is running as root (and the installer sets things up that way).
This can be (and in practice is) a blocker for some corporate environments where installing Nix could be acceptable, but running it as root is out of the question.
More generally, this is a security concern as it means running a fairly large (and not tremendously well audited) codebase as root.
Most of what Nix does however don’t require it: For the most part, everything the Nix daemon needs is to be able to write to the /nix directory.
So it should be possible to run the Nix daemon as its own dedicated user, which would also be the user of /nix.
Solution
Make it possible (and the default) to have the Nix daemon run as a non-root user
Additional context
What is root used for atm? (and how can we avoid it?)
(Possibly I’m missing some uses, please let me know if you think of something that’s not already there)
-
Writing to the Nix store. This can trivially be changed by changing the owner of the store (like in single-user mode)
-
Using the build users. This is partially redundant with the build sandbox, except that
- The build sandbox doesn’t actually change the user, which might mean that different sandboxed builds might still be able to interfere with each other
- Fixed-output derivations aren’t sandboxed
- The sandbox is costly, so the default configuration (
sandbox = relaxed) allows derivations to opt-out of it (by setting__noChroot)
Point 1. can be fixed by using a subuid mapping for the
nixuser (like all container systems do).
Point 2 and 3 can be fixed by having a light sandbox that can be used both by FO derivations and__noChrootderivations. -
The GC needs to follows the roots through the user home directories (for indirect roots).
I don’t think there’s a solution to that, so I think the root discovery system will have to be factored out into a separate executable (with a much smaller attack surface) with the right capabilities.
Activity
nixos-discourse commentedon Sep 15, 2021
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/tweag-nix-dev-update-17/15037/1
stale commentedon Apr 16, 2022
I marked this as stale due to inactivity. → More info
alexshpilkin commentedon Apr 28, 2022
Not stale, dammit.
Ericson2314 commentedon Oct 16, 2023
Is there a branch for this, even if it has conflicts?
thufschmitt commentedon Oct 17, 2023
@Ericson2314 oh, I forgot to backlink it, but yes, there's #5380 open for that (and it's essentially conflict-free barring some trivial things)
UnderTheCarpet commentedon Feb 20, 2024
Would it be also possible to change the prefix of the nix store from a hardcoded
/nix/storeto something variable/custom and potentially in the user's home?This would help to run nix as a user in a single-user scenario without requiring root (and the cooperation of your IT department ) to set up a non-user-owned folder in the file system root.
alexshpilkin commentedon Feb 20, 2024
@clamydo Currently, the Nixpkgs build system embeds absolute paths to dependencies in the build artifacts. As long as that’s true, a Nix store located in a nonstandard location (even if supported) would require rebootstrapping and rebuilding literally everything you might want to use.
[On Linux, you could live inside a mount namespace that bind-mounts the store back to the standard location, I guess, but that probably(?) doesn’t require changes to Nix.]
Ericson2314 commentedon Feb 20, 2024
Yes "chroot stores" are already supported on Linux just fine.
UnderTheCarpet commentedon Feb 21, 2024
Hmm, couldn't derivations refer to a substitutable placeholder like
$NIX_STORE_PATHthat is resolved when actually building/instantiating? For bash wrapper scripts using absolute paths this could work when a environment variable is present. pkg-config files should support variables? But there are probably places, where a resolved absolute path is strictly required?I guess
rpathneeds an absolute path and cannot be resolved at a later time 🤔?However, to me it seems that nix is nicely positioned to be a OS agnostic package/dependency manager. Requiring a folder in the root of the filesystem works just fine for NixOS but is a hindering in an more constrained environment. I feel that is a bit of a pity.
My current personal frustration with this stems from a not so cooperative sys admin responsible for my team's dev machine/server. It is hard enough to convince the rest of the team to try out 'new stuff' 😉. But also in a HPC context
nixwould just not be usable because of this requirement.alexshpilkin commentedon Feb 21, 2024
@clamydo said:
Today they refer to store paths as Nix generates them according to its own desires—which happen to go like /nix/store/ and so on, but I don’t expect the vast majority of derivations to make use of that fact. The problem is, as you said, binaries, which embed the paths and ordinarily come from a cache / substituter; I doubt you feel like building Firefox on your laptop, let alone doing a full system bootstrap including compilers and everything else.
(I don’t actually know how to bootstrap Nixpkgs from nothing but a Nix binary and a system C toolchain that may produce nonreproducible results. It’s bound to be gnarly. And bootstrapping e.g. rustc from C++ with mrustc is strictly experimental.)
Also shebangs and—crucially—the ELF interpreter1 in dynamically linked binaries. (Note we are again talking about built binaries or in any case build artifacts.)
A lot of software also just happens to bake the configured
$prefixinto random places, occasionally even as parts of compressed data. I don’t expect most of these are required per se, but patching the world to avoid it has got to be a gigantic pain (even more than it already is). It sounds like you’d need to solve content-addressed derivations first at least.Just running the damn thing in a chroot or mount namespace with /nix bind-mounted to whatever physical directory you want is bound to be simpler.
(I don’t think this situation is good or proper, to be clear; I just expect the effort of fixing it to be so large as to be functionally infinite. Unless somebody wants to get started on that :) )
Footnotes
Technically the ELF interpreter path can be relative, but then it’s relative to the working directory at time of launch, not to the directory where the launched executable is located. Not useful for our purposes. I guess you couuuld replace each binary with a statically linked wrapper that locates the correct ld.so and launches it manually with the actual executable in argv, but honestly it doesn’t sound like a good time. OK, it absolutely does, but not in a “I want to spend my life patching every piece of FOSS in the world to work with this” way. ↩