Re: [PATCH 4/4] setns.2: Document the pid, user, and mount namespace support.

On Tue, Jan 1, 2013 at 10:58 AM, Eric W. Biederman
[off-list ref] wrote:

"Michael Kerrisk (man-pages)" [off-list ref] writes:

[...]

quoted

       PID namespace of the PID namespace  of  the
       caller.

       A  multi-threaded  process  may not change user namespace
       with setns().  A process may not reassociate  the  thread
       with  the caller's user namespace.

What does the last sentence above *mean*? I don't understand it.

So the set of checks are:

        /* Don't allow gaining capabilities by reentering
         * the same user namespace.
         */
        if (user_ns == current_user_ns())
                return -EINVAL;

        /* Threaded processes may not enter a different user namespace */
        if (atomic_read(&current->mm->mm_users) > 1)
                return -EINVAL;

        if (!ns_capable(user_ns, CAP_SYS_ADMIN))
                return -EPERM;

Rereading it looks like I was going fast and suffered from dropping
important words.

A  multi-threaded  process  may not change it's user namespace
with setns().

aka if you have threads setns for a user namespace will fail.


    A process may not change the user namespace to the caller's user
    namespace via setns.  This is important because changing to a
    user namespace via setns implies gaining all caps, and you should
    not be able to gain all caps over your current user namespace.

Hopefully that clears it up.

Well, I worded it rather differently, but I hope I got it right. See below.

quoted

       A process reassociat‐
       ing itself with a user namespace must have  CAP_SYS_ADMIN
       privileges in the target user namespace.

       A process may not be reassociated with a new mount names‐
       pace if it is multi-threaded.  Changing the mount  names‐
       pace requires that the caller possess both CAP_SYS_CHROOT
       and CAP_SYS_ADMIN capabilities.

Re the last sentence: are those capabilities required in (1) the
target namespace, or (2) the source namespace, or (3) both? I suspect
(1), but please confirm.

CAP_SYS_ADMIN is required in the current user namespace.
CAP_SYS_ADMIN is required over the target mount namesapce.

CAP_SYS_CHROOT is required in the current user namespace.

Okay. See below.

So, let's take one more pass. How does the following look:

       A multi-threaded process may not  change  user  namespace  with
       setns().   It  is  not  permitted to use setns() to reenter the
       caller's current user namespace.  This prevents a  caller  that
       has  dropped capabilities from regaining those capabilities via
       a call to setns() A process reassociating itself  with  a  user
       namespace must have CAP_SYS_ADMIN privileges in the target user
       namespace.

       A process may not be reassociated with a new mount namespace if
       it  is  multi-threaded.   Changing the mount namespace requires
       that the caller possess both CAP_SYS_CHROOT  and  CAP_SYS_ADMIN
       capabilities in its own user namespace and CAP_SYS_ADMIN in the
       target mount namespace.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers