On Tue, Oct 25, 2016 at 09:56:45AM -0700, James Bottomley wrote: > On Tue, 2016-10-25 at 17:53 +0100, David Howells wrote: > > David Howells <dhowells@xxxxxxxxxx> wrote: > > > > > (2) If a process's user_namespace doesn't match that recorded in a > > > key then > > > it gets ENOKEY if it tries to refer to it or access it and > > > can't see it > > > in /proc/keys. > > > > There's another possibility here - since user_namespaces are > > hierarchical, does it make sense to let a process see keys that are > > in an ancestral namespace? > > I think that should be the decision of the owner. If you're creating a > userns to de-privilege the next user, likely you don't want this, but > if you're creating a userns to enhance it, then you do. > > I think you want to behave exactly as the mount namespace does: on > initial clone, you get a fully cloned mount tree and then you customise > it by unmounting pieces. The issue with keys is that their interface is pretty broken when exposed to user namespaces with different UID mappings, and this also causes security issues where you can get access to other users' keyrings and stuff like that. The proposed fix works around that brokenness by simply never exposing keys to other namespaces. Your suggestion would probably be more flexible, but it'll require some more, moderately ugly kernel code where various keyname prefixes are special-cased so that names with these prefixes are dynamically translated into strings containing the KUID or so. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
