On Tue, Jan 1, 2013 at 10:58 AM, Eric W. Biederman
<[email protected]> wrote:
> "Michael Kerrisk (man-pages)" <[email protected]> writes:
>
[...]
>> 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(¤t->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.
>> 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
