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

Serge E. Hallyn serue at us.ibm.com
Fri Dec 12 08:22:20 PST 2008


Quoting David Howells (dhowells at redhat.com):
> Serge E. Hallyn <serue at us.ibm.com> wrote:
> 
> > 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.
> 
> Yeah.  But it can always ask for them.
> 
> > Are there any sorts of keys X uses?
> 
> Not at the moment.
> 
> > Anyway if this set of patches does the segration correctly, I can float
> > a patch on top of these to copy the keyrings.
> 
> Each key type would need to provide an operation for copying its keys.
> 
> > 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?)
> 
> I'm not sure, and that raises an interesting point.  How do you alter the UID
> and GID of keys that you're copying?  You may have a set of keys with
> different UIDs, for example.

In fact that's the expectation, else why bother creating a new user
namespace :)

Ok so my preference is to keep them segragated and always empty on
clone(CLONE_NEWUSER), and it sounds like that's the sanest thing right
now.  Please shout if I'm misunderstanding.

> > Do you have an automated testsuite for the keyrings?  I just played
> > around with keyctl to test, since there was nothing in ltp.
> 
> Yes.
> 
> 	http://people.redhat.com/~dhowells/keys/keyutils/keyutils-tests.tar.bz2
> 
> which may need:
> 
> 	http://people.redhat.com/~dhowells/keys/keyutils/rhts_environment.sh
> 
> The tests are designed to run under RH's automated test environment.  All my
> tests are shell scripts that wrap the keyctl program.

Cool, thanks, I'll test with those.

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




More information about the Devel mailing list