[lkml]   [2011]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 05/10] user namespace: clamp down users of cap_raised
    On Mon, Oct 24, 2011 at 10:28 AM, Serge E. Hallyn
    <> wrote:
    > Quoting Andrew G. Morgan (
    >> 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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-10-25 02:45    [W:0.022 / U:0.456 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site