Quoting David Howells (dhowells@xxxxxxxxxx): > Serge E. Hallyn <serue@xxxxxxxxxx> wrote: > > > so here is a first attempt at getting keys and uid namespaces > > to play nice. The semantics need some discussion. As I recall > > Eric and yourself appeared to agree that some keyrings should > > be inherited into child user namespaces. > > Ummm... If keys are effectively a per-user-namespace resource, then they > can't be shared between namespaces. We could either duplicate all the keys > and keyrings, or we could just start afresh. The latter is certainly the > easiest. > > > I segragate them cleanly bc that appears to be the simplest thing to do > > especially given the use of i.e. lookup_by_name("uid.500"). > > Sounds reasonable. > > > IMO it shouldn't be a big problem - userspace can always list keys it wants > > into a file, start a new user namespace, then re-read them out of the > > tempfile... > > Not so. You aren't necessarily permitted to read a key - the read function > has to be supported by the key type for a start, and then you have to pass all > the security checks. I guess the question is what sorts of keys would you want a child user-namespace to inherit (that perhaps it couldn't)? The primary ones I can think of are keys for an encrypted fs. Are there any sorts of keys X uses? Anyway if this set of patches does the segration correctly, I can float a patch on top of these to copy the keyrings. But should the (automatic in-kernel) copy then still go through the security checks? (If not, is that safe, and if so, is there any advantage?) Do you have an automated testsuite for the keyrings? I just played around with keyctl to test, since there was nothing in ltp. thanks, -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers