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

[Kevin Cox]

On 18/06/17 20:16, sbaugh at catern.com wrote:
> Kevin Cox <kevincox at kevincox.ca> writes:
>> On 18/06/17 03:49, sbaugh at catern.com wrote:
>>>
>> 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).

So are you also going to stop the user from building new things? You
would also have the problem if the user was inside their quota then
started building something very large. I guess it wouldn't be bad to
start allowing this sort of enforcement but I'm not sure how useful it
would be in practice.

> 
>> 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.  

If you have two requests from the same user how do you segment them into
container or some other division? If you can restrict the containers in
some way couldn't you do this yourself by putting the links somewhere
the container can't access?

> 
> 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.
> 

Same question as above, these sound like great goals but I don't see how
the Nix daemon is going to be able to divide the requests according to
capability.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mailman.science.uu.nl/pipermail/nix-dev/attachments/20170618/463287d3/attachment.sig>