Kevin Cox <kevin...@kevincox.ca> writes: > On 18/06/17 03:49, sba...@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. _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev