Quoting David Howells (dhowells@xxxxxxxxxx): > Eric W. Biederman <ebiederm@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers