[Devel] Re: [PATCH 0/3] keys: play nicely with user namespaces

[Serge E. Hallyn]

Quoting David Howells (dhowells at redhat.com):
> Eric W. Biederman <ebiederm at xmission.com> wrote:
> 
> > So far the design is that user namespaces are disjoint with one specific
> > exception.
> > 
> > The user who creates the user namespace is expected to have god like powers
> > over all users in the created user namespace.
> 
> I see.
> 
> > When carefully implemented will allow a user namespace to be created with
> > normal user permissions and for the user that created user namespace to
> > manage the resources owned by users in that user namespace.
> 
> I'm not sure how to deal with this wrt keys.  There are two problems to
> consider:
> 
>  (1) Should a key with UID 500 from namespace A in Serge's example be visible
>      in namespace B?

Conceptually that'd be nice, but it seems unnecessary since (IIUC)
userspace in the child userns can always reload the key.  So then
we can leverage the intricate fs controls (where in fact a file may
be owned by (A,500) and (B,0) simultaneoushly, or by (A,500) with
no visibility by (B,0), while keeping the keys access controls simpler.

That's why I'm keeping them strictly separate in the current patchset.
If that turns out to be too simplistic, then we can always enable
cross-userns visibility later.

>      If such a key should show up in namespace B, should its UID be given as 0
>      to userspace?

That is the model we want for filesystem, but I'm really hoping we can
keep the keys model simpler.

>  (2) How is the quota controlled?  Do new keys made up under the domain of
>      namespace B go to namespace B UID 0's quota?  Or do they come out of
>      namespace A's UID 500 quota?

Ideally it would be both.  Since the namespaces are hierarchical, the
requirement of safe unprivileged user-namespace cloning should hold
in a child user-ns too, so at each level we want keys being counted
toward the quota of the acting (uid,userns) as well as that of each
(uidX,usernsX) up the creator chain.

-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers