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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Eric,

Some questions below.

On Tue, Nov 27, 2012 at 1:48 AM, Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
> ---
>  man2/setns.2 |   41 +++++++++++++++++++++++++++++++++--------
>  1 files changed, 33 insertions(+), 8 deletions(-)
>
> diff --git a/man2/setns.2 b/man2/setns.2
> index 6aa01e1..63b04dc 100644
> --- a/man2/setns.2
> +++ b/man2/setns.2
> @@ -48,6 +48,18 @@ must refer to a network namespace.
>  .BR CLONE_NEWUTS
>  .I fd
>  must refer to a UTS namespace.
> +.TP
> +.BR CLONE_NEWPID
> +.I fd
> +must refer to a PID namespace.
> +.TP
> +.BR CLONE_NEWUSER
> +.I fd
> +must refer to a user namespace.
> +.TP
> +.BR CLONE_NEWNS
> +.I fd
> +must refer to a mount namespace.
>  .PP
>  Specifying
>  .I nstype
> @@ -63,6 +75,25 @@ and wants to ensure that the namespace is of a particular type.
>  .IR fd
>  if the file descriptor was opened by another process and, for example,
>  passed to the caller via a UNIX domain socket.)
> +
> +The pid namespace is a little different.  Reassociating the calling
> +thread with a pid namespace only changes the pid namespace that the
> +child processes will be created in.
> +
> +Changing the pid namespace for child processes is only allowed if the
> +pid namespace specified by
> +.IR fd
> +is a child pid namespace of the pid namespace of the current thread.

I assume "current thread" above should be "calling thread", right?

> +
> +A multi-threaded process may not change user namespace with setns.  A
> +process may not reassociate the thread with the current user
> +namespace.

What do you mean by "the current user nsamesapce"?

> The 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

I tried to verify the precdeing two lines from the kernel source, but
did not work out where this check is made. Where is it?

> or it does not possess both CAP_SYS_CHROOT privileges
> +and CAP_SYS_ADMIN rights over the target mount namespace.

Could you please expand/clarify the preceding two lines. As they
stand, I don't really understand them.

>  .SH RETURN VALUE
>  On success,
>  .IR setns ()
> @@ -94,7 +125,8 @@ for this operation.
>  The
>  .BR setns ()
>  system call first appeared in Linux in kernel 3.0;
> -library support was added to glibc in version 2.14.
> +library support was added to glibc in version 2.14;
> +Support for PID, user and mount namespaces first appeard in Linux in kernel 3.8.
>  .SH CONFORMING TO
>  The
>  .BR setns ()
> @@ -106,13 +138,6 @@ a new thread is created using
>  can be changed using
>  .BR setns ().
>  .SH BUGS
> -The PID namespace and the mount namespace are not currently supported.
> -(See the descriptions of
> -.BR CLONE_NEWPID
> -and
> -.BR CLONE_NEWNS
> -in
> -.BR clone (2).)
>  .SH SEE ALSO
>  .BR clone (2),
>  .BR fork (2),

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux