[lkml]   [2011]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/9] security: Make capabilities relative to the user namespace.
    On 02/17/2011 04:03 PM, Serge E. Hallyn wrote:
    > - Introduce ns_capable to test for a capability in a non-default
    > user namespace.
    > - Teach cap_capable to handle capabilities in a non-default
    > user namespace.
    > The motivation is to get to the unprivileged creation of new
    > namespaces. It looks like this gets us 90% of the way there, with
    > only potential uid confusion issues left.
    > I still need to handle getting all caps after creation but otherwise I
    > think I have a good starter patch that achieves all of your goals.
    > Changelog:
    > 11/05/2010: [serge] add apparmor
    > 12/14/2010: [serge] fix capabilities to created user namespaces
    > Without this, if user serge creates a user_ns, he won't have
    > capabilities to the user_ns he created. THis is because we
    > were first checking whether his effective caps had the caps
    > he needed and returning -EPERM if not, and THEN checking whether
    > he was the creator. Reverse those checks.
    > 12/16/2010: [serge] security_real_capable needs ns argument in !security case
    > 01/11/2011: [serge] add task_ns_capable helper
    > 01/11/2011: [serge] add nsown_capable() helper per Bastian Blank suggestion
    > 02/16/2011: [serge] fix a logic bug: the root user is always creator of
    > init_user_ns, but should not always have capabilities to
    > it! Fix the check in cap_capable().
    > Signed-off-by: Eric W. Biederman<>
    > Signed-off-by: Serge E. Hallyn<>
    > ---

    Acked-by: Daniel Lezcano <>

     \ /
      Last update: 2011-02-19 00:47    [W:0.019 / U:1.468 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site