Messages in this thread | | | Date | Mon, 24 Oct 2011 17:43:25 -0700 | Subject | Re: [PATCH 05/10] user namespace: clamp down users of cap_raised | From | "Andrew G. Morgan" <> |
| |
On Mon, Oct 24, 2011 at 10:28 AM, Serge E. Hallyn <serge.hallyn@canonical.com> wrote: > Quoting Andrew G. Morgan (morgan@kernel.org): >> Serge, >> >> It seems as if this whole thing is really idiomatic. How about? >> >> #define IN_ROOT_USER_NS_CAPABLE(cap) \ >> ((current_user_ns() == &init_user_ns) && cap_raised(current_cap(), cap)) > > My objection to this was that it seems to encourage others to use it :) I'm > not sure we want that. Also, IN_ROOT_USER_NS seems more generally useful.
What is driving the choice of when its appropriate? How can a developer determine this? If you make it hard, presumably folk won't do it by default, but will that create a burdon on others to go round patching things like this up?
> But if I'm the only one who feels this way I'll go ahead and do it...
I'm more of a optimize for a human to read the source code (ie. debug a problem) kind of person. If IN_ROOT_USER_NS is useful, you could always define IN_ROOT_USER_NS_CAPABLE in terms of IN_ROOT_USER_NS && ... and provide both.
I guess I'm unclear, however, when you want developers to use one or the other variant of the basic capable() functionality. Since I'm not clear, I'm suspecting this is a fragile situation.
Cheers
Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |