Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > David Howells <dhowells@xxxxxxxxxx> writes: > > > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > >> > 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. > > > > Maybe the simplest is to put a 'stop here' flag on a user_namespace. Then > > when we look to see if a key is in the caller's namespace, we go up the tree > > until we hit the flag. If you don't find the key's ns within the caller's > > permitted subtree, you don't get to see the key. > > Let me just say we already have all of that (in a much nicer format) by > limiting the set of keys we can access to the set of users visible in > the user namespace. Except that we don't. Users outside of a namespace can see any key that grants permissions to 'other' - though this is something we don't do by default. David _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
