From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [PATCH 4/4] setns.2: Document the pid, user, and mount namespace support. Date: Mon, 07 Jan 2013 15:58:46 -0800 Message-ID: <8738yc5yvd.fsf@xmission.com> References: <87a9u4rmz0.fsf@xmission.com> <87k3t7q39u.fsf@xmission.com> <87bodftmv0.fsf@xmission.com> <87mwwt2pj8.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: (Michael Kerrisk's message of "Mon, 7 Jan 2013 10:51:04 +0100") Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Cc: Linux API , "Serge E. Hallyn" , Linux Containers List-Id: linux-api@vger.kernel.org "Michael Kerrisk (man-pages)" writes: > 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. That wording looks correct. Eric