Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@xxxxxxxxxx):
...
> >> 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...
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
