Re: [PATCHv2 2/2] userns: control capabilities of some user namespaces

["Serge E. Hallyn" <serge@hallyn.com>]

Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com):
...
> >> diff --git a/security/commoncap.c b/security/commoncap.c
> >> index fc46f5b85251..89103f16ac37 100644
> >> --- a/security/commoncap.c
> >> +++ b/security/commoncap.c
> >> @@ -73,6 +73,14 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
> >>  {
> >>       struct user_namespace *ns = targ_ns;
> >>
> >> +     /* If the capability is controlled and user-ns that process
> >> +      * belongs-to is 'controlled' then return EPERM and no need
> >> +      * to check the user-ns hierarchy.
> >> +      */
> >> +     if (is_user_ns_controlled(cred->user_ns) &&
> >> +         is_capability_controlled(cap))
> >> +             return -EPERM;
> >
> > I'd be curious to see the performance impact on this on a regular
> > workload (kernel build?) in a controlled ns.
> >
> Should it affect? If at all, it should be +ve since, the recursive
> user-ns hierarchy lookup is avoided with the above check if the
> capability is controlled.

Yes but I expect that to be the rare case for normal lxc installs
(which are of course what I am interested in)

>  The additional cost otherwise is this check
> per cap_capable() call.

And pipeline refetching?

Capability calls also shouldn't be all that frequent, but still I'm
left wondering...