Multi-user secure nix store? User quotas?

Hi Nixs,

Nix claims “non-privileged users can securely install software.” However, a user could fill up the nix store. Has anybody thought about how this can be mitigated? Quotas seem complicated, because the closure size of a user quota isn’t really relevant without knowing the overlap with other closures.

Two ideas come to my mind:

  1. Measure the relative closure size compared to the other users and use relative quotas or something like that. Probably complicated to invent a meaningful measure and to implement?
  2. Use classical quotas and user specific nix stores via chroot. But then, there is plenty of wasted space (without deduplication).

Has anybody used real multi-user NixOS?
Has anyone thought about this problem? Or is there even a canonical answer to it (due to Mark Shuttleworth or the pope – decide yourself)?


1 Like

Yes, this is a bit of a tricky issue — there are lots of denial-of-service vectors, not just store space consumption but also memory and compute resource consumption (run a build that never exits and eats memory and idle-loops the CPU). --keep-failed can also be used to create directories in /tmp that the responsible user can’t even delete themselves! This isn’t a use case/threat model that’s generally been considered with nix as far as I can tell: it does assume that users are polite :slight_smile:

That said, space usage by user is probably the easiest to handle ­— it could be determined by measuring the closure size of all paths in /nix/var/nix/profiles/per-user/$user, /nix/var/nix/gcroots/per-user/$user, and all symlinks pointing to a path owned by $user in /nix/var/nix/gcroots/auto. This will result in overlap between users’ store paths (i.e. total space consumption <= sum of users’ consumption) and doesn’t take store optimisation into account (i.e. total effective space consumption due to the user <= space consumption reported for the user), but might be a good start (combined with frequent garbage collection).

A more principled solution covering more aspects of the problem could be based on this if it’s ever implemented: