From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: [PATCH 0/3] keys: play nicely with user namespaces Date: Fri, 12 Dec 2008 08:17:07 -0600 Message-ID: <20081212141707.GB9571@us.ibm.com> References: <20081211232323.GA8343@us.ibm.com> <3507.1229086294@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <3507.1229086294-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: David Howells Cc: Linux Containers , "Eric W. Biederman" List-Id: containers.vger.kernel.org Quoting David Howells (dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org): > Serge E. Hallyn 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