Re: Keyrings, user namespaces and the user_struct

[David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:

> David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> 
> > James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> 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