[Nix-dev] In multi-user Nix, let the daemon handle creation of GC roots

[sbaugh at catern.com]

Kevin Cox <kevincox at kevincox.ca> writes:
> On 18/06/17 03:49, sbaugh at catern.com wrote:
>>
>> It seems to me that it would be useful for the daemon to handle making
>> GC roots, and forbid users to directly create GC roots.
>>
>> The features that come to mind:
>> - Allows later implementing policy about GC roots/space consumption
>> - Allows avoiding complicated locking around doing GC
>> - Allows /nix to be put on network storage transparently
>> - Allows /nix to be shared between containers transparently
>
> I'm not sure just this will solve your problem, however it might be a
> good start. For example if the daemon only created indirect roots then
> each root is accounted for (based on where it points) and can be cleaned
> up by either the system or the user.
>
> That being said I'm not sure this is necssary. You can already
> inspect/delete roots by a given user to see how much space they are
> "using".

Yes, but that's a post-hoc check which can't really be made to work
reliably. What do you do if a user is using too much space? Delete their
stuff without any warning? That's unworkable, instead there should be an
error at the time that the user tries to consume excess
space. (Admittedly the policy around this will be tricky, but currently
we don't even have the mechanism to write such policy).

> I'm curious what you would want to do to help with containers,
> or to help with putting nix on network storage. I don't see how this is
> required.

It helps because it allows moving away from user-based control over GC
roots. Imagine two separate independent services running as the same
user in containers built with Nix. The two services have to run as the
same user because we don't have privileges on the system to create new
users. Those two services shouldn't be allowed to remove each others' GC
roots or add GC roots using each others' credentials. We should be able
to give the services conditional access to creating GC roots, without
full access to a per-user directory; we can do that if GC roots are
created through IPC.  

A similar issue exists for multiple hosts sharing a store. Those hosts
shouldn't need to have the exact same set of users, just to share a
store. I should be able to publish my store so it is publicly accessible
to the world at large, and then allow people to connect in
(authenticating in some way) to the nix-daemon managing that store and
register new GC roots so they can maintain deployments out of that
global store. This is a lot easier than requiring the use of NFS with
POSIX user accounts which authenticate via Kerberos (or don't
authenticate at all, in traditional NFS).

The basic issue is tying control over GC roots to Unix user accounts.
Per-user software deployment is great and a big advance over root-only
software deployment, but Unix users have two fatal practical flaws: They
require privileges to create and they don't straightforwardly work
across the network. This hurts using a single store for multiple
containers on a single box, as well as using a single store across an
untrusting network.

And the more fundamental issue is that Unix users aren't compatible with
a capability-security model, which hopefully Nix can help push the world
towards. I would like to be able to give out a capability for creating
GC roots; that's not possible with the current user-based mechanism.

Hopefully that makes sense? I am fairly new to Nix, but I'm coming at
this from a capability-security mindset, and want to make sure Nix is as
compatible as possible with cap-security.