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.
> 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.
That adds quite a bit of complexity, given that:
(1) we don't have an automatic updating view of a keyring as the cloned mount
tree does;
(2) there are quotas on the number of keys a user is permitted;
(3) you may not have permission to 'dismount' part of the tree.
That said, it might be enough to just clone the *keyrings* and share the
non-keyring keys.
David
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
