Re: For review: pid_namespaces(7) man page

Re: For review: pid_namespaces(7) man page

[Vasily Kulikov]

Hi Michael,

On Thu, Feb 28, 2013 at 12:24 +0100, Michael Kerrisk (man-pages) wrote:
>    The namespace init process
>        The first process created in a new namespace (i.e., the process
>        created using clone(2) with the CLONE_NEWPID flag, or the first
>        child created by a process after a call to unshare(2) using the
>        CLONE_NEWPID flag) has the PID 1, and is the "init" process for
>        the namespace (see init(1)).  Children that are orphaned within
>        the namespace will be reparented to this  process  rather  than
>        init(1).

Probably it worth noting here that this is true unless
prctl() with PR_SET_CHILD_SUBREAPER option is called.

Thanks,

-- 
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments

Re: For review: pid_namespaces(7) man page

[Eric W. Biederman]

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

> Eric et al,
>
> Eventually, there will be more namespace man pages, but let us start
> now with one for PID namespaces. The attached page aims to provide a
> fairly complete overview of PID namespaces.
>
> Eric, various pieces of the page are shifted out of other pages
> (clone(2), setns(2), etc.) and are derived from comments you've
> emailed me off list, so you are (jointly) in the copyright of the
> page. I've chosen the common license for man-pages; let me know if you
> have any objections to that license.

Interesting license.  It seems reasonable.

> I'm looking for review comments (corrections, improvements, additions,
> etc.) on this page. I've provided it in two forms inline below, and
> reviewers can comment comment on whichever form they are most
> comfortable with:
>
> 1) The rendered page as plain text
> 2) The *roff source (also attached); rendering that source will enable
> readers to see proper formatting for the page.
>
> Note that the namespaces(7) page referred to in this page is not yet
> finished; I'll send it out for review at a future time.
>
> Thanks,
>
> Michael
>
> ==========
> PID_NAMESPACES(7)      Linux Programmer's Manual     PID_NAMESPACES(7)
>
> NAME
>        pid_namespaces - overview of Linux PID namespaces
>
> DESCRIPTION
>        For an overview of namespaces, see namespaces(7).
>
>        PID  namespaces  isolate  the  process ID number space, meaning
>        that processes in different PID namespaces can  have  the  same
>        PID.   PID namespaces allow containers to migrate to a new host
>        while the processes inside  the  container  maintain  the  same
>        PIDs.
>
>        PIDs  in a new PID namespace start at 1, somewhat like a stand‐
>        alone system, and calls to fork(2), vfork(2), or clone(2)  will
>        produce  processes  with PIDs that are unique within the names‐
>        pace.
>
>        Use of PID namespaces requires a kernel that is configured with
>        the CONFIG_PID_NS option.
>
>    The namespace init process
>        The first process created in a new namespace (i.e., the process
>        created using clone(2) with the CLONE_NEWPID flag, or the first
>        child created by a process after a call to unshare(2) using the
>        CLONE_NEWPID flag) has the PID 1, and is the "init" process for
>        the namespace (see init(1)).  Children that are orphaned within
>        the namespace will be reparented to this  process  rather  than
>        init(1).
>
>        If the "init" process of a PID namespace terminates, the kernel
>        terminates all of the processes in the namespace via a  SIGKILL
>        signal.   This  behavior  reflects  the  fact  that  the "init"
>        process is essential for the correct operation of a PID  names‐
>        pace.   In this case, a subsequent fork(2) into this PID names‐
>        pace (e.g., from a process that has done a  setns(2)  into  the
>        namespace    using    an    open    file   descriptor   for   a
>        /proc/[pid]/ns/pid file corresponding to a process that was  in
>        the  namespace) will fail with the error ENOMEM; it is not pos‐
>        sible to create a new processes in a PID namespace whose "init"
>        process has terminated.

It may be useful to mention unshare in the case of fork(2) failing just
because that is such an easy mistake to make.

unshare(CLONE_NEWPID);
pid = fork();
waitpid(pid,...);
fork() -> ENOMEM 

>        Only  signals  for  which  the "init" process has established a
>        signal handler can be sent to the "init" process by other  mem‐
>        bers  of  the  PID namespace.  This restriction applies even to
>        privileged processes, and prevents other  members  of  the  PID
>        namespace from accidentally killing the "init" process.
>
>        Likewise, a process in an ancestor namespace can—subject to the
>        usual permission checks described in  kill(2)—send  signals  to
>        the  "init" process of a child PID namespace only if the "init"
>        process has established a handler for that signal.  (Within the
>        handler,  the  siginfo_t si_pid field described in sigaction(2)
>        will be zero.)  SIGKILL or SIGSTOP are  treated  exceptionally:
>        these signals are forcibly delivered when sent from an ancestor
>        PID namespace.  Neither of these signals can be caught  by  the
>        "init" process, and so will result in the usual actions associ‐
>        ated with those signals (respectively, terminating and stopping
>        the process).
>
>    Nesting PID namespaces
>        PID  namespaces can be nested: each PID namespace has a parent,
>        except for the initial ("root") PID namespace.  The parent of a
>        PID  namespace is the PID namespace of the process that created
>        the namespace using clone(2)  or  unshare(2).   PID  namespaces
>        thus  form a tree, with all namespaces ultimately tracing their
>        ancestry to the root namespace.
>
>        A process is visible to other processes in its  PID  namespace,
>        and  to  the  processes  in  each direct ancestor PID namespace
>        going back to the root PID namespace.  In this context,  "visi‐
>        ble"  means that one process can be the target of operations by
>        another process using system calls that specify a  process  ID.
>        Conversely,  the  processes  in a child PID namespace can't see
>        processes in the parent and further removed ancestor namespace.
>        More  succinctly:  a  process  can see (e.g., send signals with
>        kill(2), set nice values with setpriority(2), etc.)  only  pro‐
>        cesses contained in its own PID namespace and in descendants of
>        that namespace.
>
>        A process has one process ID in each of the layers of  the  PID
>        namespace  hierarchy  in  which  is  visible,  and walking back
>        though each direct ancestor namespace through to the  root  PID
>        namespace.   System  calls  that  operate on process IDs always
>        operate using the process ID that is visible in the PID  names‐
>        pace of the caller.  A call to getpid(2) always returns the PID
>        associated with the namespace in which the process was created.
>
>        Some processes in a PID namespace may  have  parents  that  are
>        outside  of the namespace.  For example, the parent of the ini‐
>        tial process in the namespace (i.e., the init(1)  process  with
>        PID  1)  is  necessarily  in  another namespace.  Likewise, the
>        direct children of a process that uses setns(2)  to  cause  its
>        children  to join a PID namespace are in a different PID names‐
>        pace from the caller of setns(2).  Calls to getppid(2) for such
>        processes return 0.
>
>    setns(2) and unshare(2) semantics
>        Calls  to setns(2) that specify a PID namespace file descriptor
>        and calls to unshare(2) with the CLONE_NEWPID flag cause  chil‐
>        dren  subsequently created by the caller to be placed in a dif‐
>        ferent PID namespace from the caller.  These calls do not, how‐
>        ever,  change the PID namespace of the calling process, because
>        doing so would change the caller's idea  of  its  own  PID  (as
>        reported  by getpid()), which would break many applications and
>        libraries.
>
>        To put things another way: a process's PID namespace membership
>        is determined when the process is created and cannot be changed
>        thereafter.  Among other things, this means that  the  parental
>        relationship between processes mirrors the parental between PID
>        namespaces: the parent of a  process  is  either  in  the  same
>        namespace or resides in the immediate parent PID namespace.

This is mostly true.  With setns it is possible to have a parent
in a pid namespace several steps up the pid namespace hierarchy.

>        Every  thread  in  a process must be in the same PID namespace.
>        For this reason, the two following call sequences will fail:
>
>            unshare(CLONE_NEWPID);
>            clone(..., CLONE_VM, ...);    /* Fails */
>
>            setns(fd, CLONE_NEWPID);
>            clone(..., CLONE_VM, ...);    /* Fails */
>
>        Because the above unshare(2) and setns(2) calls only change the
>        PID  namespace  for created children, the clone(2) calls neces‐
>        sarily put the new thread in a different PID namespace from the
>        calling thread.

I don't know if it is interesting but these sequences also fail.  But I
suppose that is obvious?  Or documented at least Documented in the clone
manpage and unshare manpages.

            clone(..., CLONE_VM, ...);
            unshare(CLONE_NEWPID);       /* Fails */

            clone(..., CLONE_VM, ...);
            setns(fd, CLONE_NEWPID);     /* Fails */
              
>    Miscellaneous
>        After  creating a new PID namespace, it is useful for the child
>        to change its root directory and mount a new procfs instance at
>        /proc  so  that  tools such as ps(1) work correctly.  (If a new
>        mount  namespace  is  simultaneously   created   by   including
>        CLONE_NEWNS  in  the flags argument of clone(2) or unshare(2)),
>        then it isn't necessary to change the  root  directory:  a  new
>        procfs instance can be mounted directly over /proc.)

Should it be documented somewhere that /proc when mounted from a pid
namespace will use the pids of that pid namespace and /proc will only
show process for visible in the mounting pid namespace, even if that
mount of proc is accessed by processes in other pid namespaces?

You sort of say it here by saying it is useful to mount a new copy of
/proc, which it is.  I just don't see you coming out straight and saying
why it is.  It just seems to be implied.

>        Calling  readlink(2)  on the path /proc/self yields the process
>        ID of the caller in the  PID  namespace  of  the  procfs  mount
>        (i.e.,  the  PID  namespace  of  the  process  that mounted the
>        procfs).
>
>        When a process ID is passed over a  UNIX  domain  socket  to  a
>        process  in  a  different PID namespace (see the description of
>        SCM_CREDENTIALS in unix(7)), it is translated into  the  corre‐
>        sponding PID value in the receiving process's PID namespace.
>
> CONFORMING TO
>        Namespaces are a Linux-specific feature.
>
> SEE ALSO
>        unshare(1),  clone(2),  setns(2),  unshare(2), proc(5), creden‐
>        tials(7), capabilities(7), user_namespaces(7), switch_root(8)
>
>
>
> Linux                         2013-01-14             PID_NAMESPACES(7)
>
>
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: For review: pid_namespaces(7) man page

[Rob Landley]

On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
> Eric et al,
> 
> Eventually, there will be more namespace man pages, but let us start
> now with one for PID namespaces. The attached page aims to provide a
> fairly complete overview of PID namespaces.

Onward!

> PID_NAMESPACES(7)      Linux Programmer's Manual     PID_NAMESPACES(7)
> 
> NAME
>        pid_namespaces - overview of Linux PID namespaces
> 
> DESCRIPTION
>        For an overview of namespaces, see namespaces(7).
> 
>        PID  namespaces  isolate  the  process ID number space, meaning
>        that processes in different PID namespaces can  have  the  same
>        PID.

Um, perhaps "different processes"? Slightly repetitive, but trying to  
avoid the potential misreading that "a processes can have the same PID  
in different namespaces". (A single process can't be a member of more  
than one namespace. This is not about selective visibility.)

> PID namespaces allow containers to migrate to a new host
>        while the processes inside  the  container  maintain  the  same
>        PIDs.

I thought suspend/resume a container was the simple case. Migration to  
a new host is built on top of that. (On resume in a new container on  
the same system, if other stuff is going on in the system so the  
available PIDs have shifted.)

>        Likewise, a process in an ancestor namespace can—subject to the
>        usual permission checks described in  kill(2)—send  signals  to
>        the  "init" process of a child PID namespace only if the "init"
>        process has established a handler for that signal.  (Within the
>        handler,  the  siginfo_t si_pid field described in sigaction(2)
>        will be zero.)  SIGKILL or SIGSTOP are  treated  exceptionally:
>        these signals are forcibly delivered when sent from an ancestor
>        PID namespace.  Neither of these signals can be caught  by  the
>        "init" process, and so will result in the usual actions associ‐
>        ated with those signals (respectively, terminating and stopping
>        the process).

If SIGKILL to init is propogated to all the children of init, is  
SIGSTOP also propogated to all the children? (I.E. will SIGSTOP to  
container's init suspend the whole container, and will SIGCONT resume  
the whole container? If the latter, will it only resume processes that  
weren't previously stopped? :)

>        To put things another way: a process's PID namespace membership
>        is determined when the process is created and cannot be changed
>        thereafter.  Among other things, this means that  the  parental
>        relationship between processes mirrors the parental between PID

mirrors the relationship

>        namespaces: the parent of a  process  is  either  in  the  same
>        namespace or resides in the immediate parent PID namespace.
> 
>        Every  thread  in  a process must be in the same PID namespace.
>        For this reason, the two following call sequences will fail:
> 
>            unshare(CLONE_NEWPID);
>            clone(..., CLONE_VM, ...);    /* Fails */
> 
>            setns(fd, CLONE_NEWPID);
>            clone(..., CLONE_VM, ...);    /* Fails */

They fail with -EUNDOCUMENTED

>        Because the above unshare(2) and setns(2) calls only change the
>        PID  namespace  for created children, the clone(2) calls neces‐
>        sarily put the new thread in a different PID namespace from the
>        calling thread.

Um, no they don't. They fail. That's the point. They _would_ put the  
new thread in a different PID namespace, which breaks the definition of  
threads.

How about:

The above unshare(2) and setns(2) calls change the PID namespace of
children created by subsequent clone(2) calls, which is incompatible
with CLONE_VM.

>    Miscellaneous
>        After  creating a new PID namespace, it is useful for the child
>        to change its root directory and mount a new procfs instance at
>        /proc  so  that  tools such as ps(1) work correctly.  (If a new
>        mount  namespace  is  simultaneously   created   by   including
>        CLONE_NEWNS  in  the flags argument of clone(2) or unshare(2)),
>        then it isn't necessary to change the  root  directory:  a  new
>        procfs instance can be mounted directly over /proc.)

Why is the (If) clause in parentheses? And unshare(2)) has a Bruce.
(I.E. unbalanced parens.).

>        Calling  readlink(2)  on the path /proc/self yields the process
>        ID of the caller in the  PID  namespace  of  the  procfs  mount
>        (i.e.,  the  PID  namespace  of  the  process  that mounted the
>        procfs).

This is per-filesystem rather than using the process's namespace  
because...?
(Where /proc/self points is already process-local data, so the races  
here can't be too horrible...)

>        When a process ID is passed over a  UNIX  domain  socket  to  a
>        process  in  a  different PID namespace (see the description of
>        SCM_CREDENTIALS in unix(7)), it is translated into  the  corre‐
>        sponding PID value in the receiving process's PID namespace.

Heh. :)

> CONFORMING TO
>        Namespaces are a Linux-specific feature.

And yet the glibc guys insist on #define GNU_GNU_GNU_ALL_HAIL_STALLMAN  
in order to access this Linux-specific feature which has nothing  
whatsoever to do with the FSF.

The unshare() call originally _didn't_ require this define, but they  
retroactively added the requirement in a version "upgrade" to match  
your man page. This made me sad. It also made me prototype it myself  
rather than expecting the header to provide it.

Rob
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: For review: pid_namespaces(7) man page

[Eric W. Biederman]

Rob Landley <rob@landley.net> writes:

> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
>> Eric et al,
>> 
>> Eventually, there will be more namespace man pages, but let us start
>> now with one for PID namespaces. The attached page aims to provide a
>> fairly complete overview of PID namespaces.
>
> Onward!
>
>> PID_NAMESPACES(7)      Linux Programmer's Manual     PID_NAMESPACES(7)
>> 
>> NAME
>>        pid_namespaces - overview of Linux PID namespaces
>> 
>> DESCRIPTION
>>        For an overview of namespaces, see namespaces(7).
>> 
>>        PID  namespaces  isolate  the  process ID number space, meaning
>>        that processes in different PID namespaces can  have  the  same
>>        PID.
>
> Um, perhaps "different processes"? Slightly repetitive, but trying to  
> avoid the potential misreading that "a processes can have the same PID  
> in different namespaces". (A single process can't be a member of more  
> than one namespace. This is not about selective visibility.)

Well actually a process is visible and arguably a member of all parent
pid namespaces, and a process certainly had a pid value in each pid
namespace up to the root of the pid namespace tree.

>> PID namespaces allow containers to migrate to a new host
>>        while the processes inside  the  container  maintain  the  same
>>        PIDs.
>
> I thought suspend/resume a container was the simple case. Migration to  
> a new host is built on top of that. (On resume in a new container on  
> the same system, if other stuff is going on in the system so the  
> available PIDs have shifted.)

I don't know if there is a difference at the implementation level.

>>        Likewise, a process in an ancestor namespace can—subject to the
>>        usual permission checks described in  kill(2)—send  signals  to
>>        the  "init" process of a child PID namespace only if the "init"
>>        process has established a handler for that signal.  (Within the
>>        handler,  the  siginfo_t si_pid field described in sigaction(2)
>>        will be zero.)  SIGKILL or SIGSTOP are  treated  exceptionally:
>>        these signals are forcibly delivered when sent from an ancestor
>>        PID namespace.  Neither of these signals can be caught  by  the
>>        "init" process, and so will result in the usual actions associ‐
>>        ated with those signals (respectively, terminating and stopping
>>        the process).
>
> If SIGKILL to init is propogated to all the children of init, is  
> SIGSTOP also propogated to all the children? (I.E. will SIGSTOP to  
> container's init suspend the whole container, and will SIGCONT resume  
> the whole container? If the latter, will it only resume processes that  
> weren't previously stopped? :)

No.  SIGSTOP stops sent to init stops just init.

It isn't SIGKILL that is propogated it is the exiting of init that is
propogated by way of SIGKILL.  If your init process calls _exit() or
hits a SIGSEGV and dies all of the other processes in the pid namespace
will be sent a SIGKILL and be forced down.

This is similar to a the system panic if the global init exits.

>>        To put things another way: a process's PID namespace membership
>>        is determined when the process is created and cannot be changed
>>        thereafter.  Among other things, this means that  the  parental
>>        relationship between processes mirrors the parental between PID
>
> mirrors the relationship
>
>>        namespaces: the parent of a  process  is  either  in  the  same
>>        namespace or resides in the immediate parent PID namespace.
>> 
>>        Every  thread  in  a process must be in the same PID namespace.
>>        For this reason, the two following call sequences will fail:
>> 
>>            unshare(CLONE_NEWPID);
>>            clone(..., CLONE_VM, ...);    /* Fails */
>> 
>>            setns(fd, CLONE_NEWPID);
>>            clone(..., CLONE_VM, ...);    /* Fails */
>
> They fail with -EUNDOCUMENTED
Make that -EINVAL.

>>        Because the above unshare(2) and setns(2) calls only change the
>>        PID  namespace  for created children, the clone(2) calls neces‐
>>        sarily put the new thread in a different PID namespace from the
>>        calling thread.
>
> Um, no they don't. They fail. That's the point. They _would_ put the  
> new thread in a different PID namespace, which breaks the definition of  
> threads.
>
> How about:
>
> The above unshare(2) and setns(2) calls change the PID namespace of
> children created by subsequent clone(2) calls, which is incompatible
> with CLONE_VM.
>
>>    Miscellaneous
>>        After  creating a new PID namespace, it is useful for the child
>>        to change its root directory and mount a new procfs instance at
>>        /proc  so  that  tools such as ps(1) work correctly.  (If a new
>>        mount  namespace  is  simultaneously   created   by   including
>>        CLONE_NEWNS  in  the flags argument of clone(2) or unshare(2)),
>>        then it isn't necessary to change the  root  directory:  a  new
>>        procfs instance can be mounted directly over /proc.)
>
> Why is the (If) clause in parentheses? And unshare(2)) has a Bruce.
> (I.E. unbalanced parens.).
>
>>        Calling  readlink(2)  on the path /proc/self yields the process
>>        ID of the caller in the  PID  namespace  of  the  procfs  mount
>>        (i.e.,  the  PID  namespace  of  the  process  that mounted the
>>        procfs).
>
> This is per-filesystem rather than using the process's namespace  
> because...? 

The entire proc filesystem mount is in the pid namespace of the mounting
process.  Every pid that proc reports.  /proc/self is not a special
case, but /proc/self can be interesting if you want to find your pid
in that other guys pid namespace.

> (Where /proc/self points is already process-local data, so the races  
> here can't be too horrible...)

It actually is moderately important for /proc/self to do the right thing
here.  It means you can run against a /proc that is not for your pid
namespace and all of the /proc/self things that glibc and various other
programs and libraries due continue to work.

>>        When a process ID is passed over a  UNIX  domain  socket  to  a
>>        process  in  a  different PID namespace (see the description of
>>        SCM_CREDENTIALS in unix(7)), it is translated into  the  corre‐
>>        sponding PID value in the receiving process's PID namespace.
>
> Heh. :)
>
>> CONFORMING TO
>>        Namespaces are a Linux-specific feature.
>
> And yet the glibc guys insist on #define GNU_GNU_GNU_ALL_HAIL_STALLMAN  
> in order to access this Linux-specific feature which has nothing  
> whatsoever to do with the FSF.

I read it _GNU_SOURCE just implies a libc extensions specific to glibc.
Of course now that you mention it _GNU_SOURCE implies that we can
reasonably file a bug against glibc on the HURD or BSD for not
implementing this feature can't we?

> The unshare() call originally _didn't_ require this define, but they  
> retroactively added the requirement in a version "upgrade" to match  
> your man page. This made me sad. It also made me prototype it myself  
> rather than expecting the header to provide it.

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

Hi Rob,

On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@landley.net> wrote:
> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
[...]

>> DESCRIPTION
>>        For an overview of namespaces, see namespaces(7).
>>
>>        PID  namespaces  isolate  the  process ID number space, meaning
>>        that processes in different PID namespaces can  have  the  same
>>        PID.
>
>
> Um, perhaps "different processes"? Slightly repetitive, but trying to avoid
> the potential misreading that "a processes can have the same PID in
> different namespaces". (A single process can't be a member of more than one
> namespace. This is not about selective visibility.)

I'm not sure this clarifies things...

>> PID namespaces allow containers to migrate to a new host
>>        while the processes inside  the  container  maintain  the  same
>>        PIDs.
>
>
> I thought suspend/resume a container was the simple case. Migration to a new
> host is built on top of that. (On resume in a new container on the same
> system, if other stuff is going on in the system so the available PIDs have
> shifted.)

I'll add some words here on suspend/resume.

>>        Likewise, a process in an ancestor namespace can—subject to the
>>        usual permission checks described in  kill(2)—send  signals  to
>>        the  "init" process of a child PID namespace only if the "init"
>>        process has established a handler for that signal.  (Within the
>>        handler,  the  siginfo_t si_pid field described in sigaction(2)
>>        will be zero.)  SIGKILL or SIGSTOP are  treated  exceptionally:
>>        these signals are forcibly delivered when sent from an ancestor
>>        PID namespace.  Neither of these signals can be caught  by  the
>>        "init" process, and so will result in the usual actions associ‐
>>        ated with those signals (respectively, terminating and stopping
>>        the process).
>
>
> If SIGKILL to init is propogated to all the children of init, is SIGSTOP
> also propogated to all the children? (I.E. will SIGSTOP to container's init
> suspend the whole container, and will SIGCONT resume the whole container? If
> the latter, will it only resume processes that weren't previously stopped?
> :)

Covered by Eric.

>>        To put things another way: a process's PID namespace membership
>>        is determined when the process is created and cannot be changed
>>        thereafter.  Among other things, this means that  the  parental
>>        relationship between processes mirrors the parental between PID
>
>
> mirrors the relationship

Thanks.

>>        namespaces: the parent of a  process  is  either  in  the  same
>>        namespace or resides in the immediate parent PID namespace.
>>
>>        Every  thread  in  a process must be in the same PID namespace.
>>        For this reason, the two following call sequences will fail:
>>
>>            unshare(CLONE_NEWPID);
>>            clone(..., CLONE_VM, ...);    /* Fails */
>>
>>            setns(fd, CLONE_NEWPID);
>>            clone(..., CLONE_VM, ...);    /* Fails */
>
>
> They fail with -EUNDOCUMENTED

Added EINVAL, as per Eric's reply. (Eric does that error also apply
for the two new cases you added?).

>>        Because the above unshare(2) and setns(2) calls only change the
>>        PID  namespace  for created children, the clone(2) calls neces‐
>>        sarily put the new thread in a different PID namespace from the
>>        calling thread.
>
>
> Um, no they don't. They fail. That's the point.

(Good catch.)

> They _would_ put the new
> thread in a different PID namespace, which breaks the definition of threads.
>
> How about:
>
> The above unshare(2) and setns(2) calls change the PID namespace of
> children created by subsequent clone(2) calls, which is incompatible
> with CLONE_VM.

I decided on:

       The  point  here is that unshare(2) and setns(2) change the PID
       namespace for created children but not for the calling process,
       while  clone(2) CLONE_VM specifies the creation of a new thread
       in the same process.

>>    Miscellaneous
>>        After  creating a new PID namespace, it is useful for the child
>>        to change its root directory and mount a new procfs instance at
>>        /proc  so  that  tools such as ps(1) work correctly.  (If a new
>>        mount  namespace  is  simultaneously   created   by   including
>>        CLONE_NEWNS  in  the flags argument of clone(2) or unshare(2)),
>>        then it isn't necessary to change the  root  directory:  a  new
>>        procfs instance can be mounted directly over /proc.)
>
>
> Why is the (If) clause in parentheses? And unshare(2)) has a Bruce.
> (I.E. unbalanced parens.).

I'll make some fixes here.

>>        Calling  readlink(2)  on the path /proc/self yields the process
>>        ID of the caller in the  PID  namespace  of  the  procfs  mount
>>        (i.e.,  the  PID  namespace  of  the  process  that mounted the
>>        procfs).
>
>
> This is per-filesystem rather than using the process's namespace because...?
> (Where /proc/self points is already process-local data, so the races here
> can't be too horrible...)

Explained by Eric.

I'll add:

[[
This can be useful for introspection purposes,
when a process wants to discover its PID in other namespaces.
]]

[...]

>> CONFORMING TO
>>        Namespaces are a Linux-specific feature.
>
>
> And yet the glibc guys insist on #define GNU_GNU_GNU_ALL_HAIL_STALLMAN in
> order to access this Linux-specific feature which has nothing whatsoever to
> do with the FSF.

This is a misunderstanding. _GNU_SOURCE is the standard way to expose
Linux-specific functionality from POSIX header files.

> The unshare() call originally _didn't_ require this define, but they
> retroactively added the requirement in a version "upgrade" to match your man
> page. This made me sad. It also made me prototype it myself rather than
> expecting the header to provide it.

Hmmm. I did not notice that change. Ulrich rejected my early (2007)
request for a change
(http://www.sourceware.org/bugzilla/show_bug.cgi?id=4749) and then
quietly made it later (glibc 2.14, 2011).

Thanks for the review, Rob.

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

Re: For review: pid_namespaces(7) man page

[Eric W. Biederman]

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

> Hi Rob,
>
> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@landley.net> wrote:
>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
> [...]
>
>>> DESCRIPTION
>>>        For an overview of namespaces, see namespaces(7).
>>>
>>>        PID  namespaces  isolate  the  process ID number space, meaning
>>>        that processes in different PID namespaces can  have  the  same
>>>        PID.
>>
>>
>> Um, perhaps "different processes"? Slightly repetitive, but trying to avoid
>> the potential misreading that "a processes can have the same PID in
>> different namespaces". (A single process can't be a member of more than one
>> namespace. This is not about selective visibility.)
>
> I'm not sure this clarifies things...
>
>>> PID namespaces allow containers to migrate to a new host
>>>        while the processes inside  the  container  maintain  the  same
>>>        PIDs.
>>
>>
>> I thought suspend/resume a container was the simple case. Migration to a new
>> host is built on top of that. (On resume in a new container on the same
>> system, if other stuff is going on in the system so the available PIDs have
>> shifted.)
>
> I'll add some words here on suspend/resume.
>
>>>        Likewise, a process in an ancestor namespace can—subject to the
>>>        usual permission checks described in  kill(2)—send  signals  to
>>>        the  "init" process of a child PID namespace only if the "init"
>>>        process has established a handler for that signal.  (Within the
>>>        handler,  the  siginfo_t si_pid field described in sigaction(2)
>>>        will be zero.)  SIGKILL or SIGSTOP are  treated  exceptionally:
>>>        these signals are forcibly delivered when sent from an ancestor
>>>        PID namespace.  Neither of these signals can be caught  by  the
>>>        "init" process, and so will result in the usual actions associ‐
>>>        ated with those signals (respectively, terminating and stopping
>>>        the process).
>>
>>
>> If SIGKILL to init is propogated to all the children of init, is SIGSTOP
>> also propogated to all the children? (I.E. will SIGSTOP to container's init
>> suspend the whole container, and will SIGCONT resume the whole container? If
>> the latter, will it only resume processes that weren't previously stopped?
>> :)
>
> Covered by Eric.
>
>>>        To put things another way: a process's PID namespace membership
>>>        is determined when the process is created and cannot be changed
>>>        thereafter.  Among other things, this means that  the  parental
>>>        relationship between processes mirrors the parental between PID
>>
>>
>> mirrors the relationship
>
> Thanks.
>
>>>        namespaces: the parent of a  process  is  either  in  the  same
>>>        namespace or resides in the immediate parent PID namespace.
>>>
>>>        Every  thread  in  a process must be in the same PID namespace.
>>>        For this reason, the two following call sequences will fail:
>>>
>>>            unshare(CLONE_NEWPID);
>>>            clone(..., CLONE_VM, ...);    /* Fails */
>>>
>>>            setns(fd, CLONE_NEWPID);
>>>            clone(..., CLONE_VM, ...);    /* Fails */
>>
>>
>> They fail with -EUNDOCUMENTED
>
> Added EINVAL, as per Eric's reply. (Eric does that error also apply
> for the two new cases you added?).
>
>>>        Because the above unshare(2) and setns(2) calls only change the
>>>        PID  namespace  for created children, the clone(2) calls neces‐
>>>        sarily put the new thread in a different PID namespace from the
>>>        calling thread.
>>
>>
>> Um, no they don't. They fail. That's the point.
>
> (Good catch.)
>
>> They _would_ put the new
>> thread in a different PID namespace, which breaks the definition of threads.
>>
>> How about:
>>
>> The above unshare(2) and setns(2) calls change the PID namespace of
>> children created by subsequent clone(2) calls, which is incompatible
>> with CLONE_VM.
>
> I decided on:
>
>        The  point  here is that unshare(2) and setns(2) change the PID
>        namespace for created children but not for the calling process,
>        while  clone(2) CLONE_VM specifies the creation of a new thread
>        in the same process.

Can we make that "for all new tasks created" instead of "created
children"

Othewise someone might expect CLONE_THREAD would work as you
CLONE_THREAD creates a thread and not a child...

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: For review: pid_namespaces(7) man page

[Rob Landley]

On 03/01/2013 03:57:40 AM, Michael Kerrisk (man-pages) wrote:
> > And yet the glibc guys insist on #define  
> GNU_GNU_GNU_ALL_HAIL_STALLMAN in
> > order to access this Linux-specific feature which has nothing  
> whatsoever to
> > do with the FSF.
> 
> This is a misunderstanding. _GNU_SOURCE is the standard way to expose
> Linux-specific functionality from POSIX header files.

What standard? The Linux kernel is not, and never was, part of the GNU  
project.

Rob

Re: For review: pid_namespaces(7) man page

[Eric W. Biederman]

Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> writes:

> On 03/01/2013 03:57:40 AM, Michael Kerrisk (man-pages) wrote:
>> > And yet the glibc guys insist on #define  
>> GNU_GNU_GNU_ALL_HAIL_STALLMAN in
>> > order to access this Linux-specific feature which has nothing  
>> whatsoever to
>> > do with the FSF.
>> 
>> This is a misunderstanding. _GNU_SOURCE is the standard way to expose
>> Linux-specific functionality from POSIX header files.
>
> What standard? The Linux kernel is not, and never was, part of the GNU  
> project.

Is the argument that there should be a _LINUX_SOURCE directive in glibc
for this?

Although come to think of it I can't imagine how <sched.h> is a POSIX
header.  Last I looked it only had linux specific bits in it.  Which
makes needing any kind of #define strange.

Eric

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

On Mon, Mar 4, 2013 at 5:03 AM, Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> writes:
>
>> On 03/01/2013 03:57:40 AM, Michael Kerrisk (man-pages) wrote:
>>> > And yet the glibc guys insist on #define
>>> GNU_GNU_GNU_ALL_HAIL_STALLMAN in
>>> > order to access this Linux-specific feature which has nothing
>>> whatsoever to
>>> > do with the FSF.
>>>
>>> This is a misunderstanding. _GNU_SOURCE is the standard way to expose
>>> Linux-specific functionality from POSIX header files.
>>
>> What standard? The Linux kernel is not, and never was, part of the GNU
>> project.
>
> Is the argument that there should be a _LINUX_SOURCE directive in glibc
> for this?
>
> Although come to think of it I can't imagine how <sched.h> is a POSIX
> header.  Last I looked it only had linux specific bits in it.  Which
> makes needing any kind of #define strange.

I think you may be thinking of the wrong sched.h. The glibc
/usr/include/sched.h declares many user-space functions from POSIX.


Cheers,

Mcihael

Re: For review: pid_namespaces(7) man page

[Rob Landley]

On 03/03/2013 10:03:55 PM, Eric W. Biederman wrote:
> Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> writes:
> 
> > On 03/01/2013 03:57:40 AM, Michael Kerrisk (man-pages) wrote:
> >> > And yet the glibc guys insist on #define
> >> GNU_GNU_GNU_ALL_HAIL_STALLMAN in
> >> > order to access this Linux-specific feature which has nothing
> >> whatsoever to
> >> > do with the FSF.
> >>
> >> This is a misunderstanding. _GNU_SOURCE is the standard way to  
> expose
> >> Linux-specific functionality from POSIX header files.
> >
> > What standard? The Linux kernel is not, and never was, part of the  
> GNU
> > project.
> 
> Is the argument that there should be a _LINUX_SOURCE directive in  
> glibc
> for this?

If you don't #define any feature test macros at all, you get a bunch of  
macros (_BSD_SOURCE, _SVID_SOURCE, _POSIX_SOURCE,  
_POSIX_C_SOURCE=200809L, and so on) defined by default in features.h.  
If you start defining macros, several of the default ones _go_away_,  
and you start missing things that are defined by posix-2008. Yes,  
defining feature test macros makes definitions _vanish_ out of the  
headers, which means feature test macros can actually reduce code  
portability.

The _GNU_SOURCE is glibc's way of saying "switch on everything glibc  
offers". (Except it isn't _quite_, but that seems to be what they  
intended.) So there are various things that test _specifically_ for  
that macro, but the macro also switches on (from features.h):

/* If _GNU_SOURCE was defined by the user, turn on all the other  
features.  */
#ifdef _GNU_SOURCE
# undef  _ISOC95_SOURCE
# define _ISOC95_SOURCE 1
# undef  _ISOC99_SOURCE
# define _ISOC99_SOURCE 1
# undef  _POSIX_SOURCE
# define _POSIX_SOURCE  1
# undef  _POSIX_C_SOURCE
# define _POSIX_C_SOURCE        200809L
# undef  _XOPEN_SOURCE
# define _XOPEN_SOURCE  700
# undef  _XOPEN_SOURCE_EXTENDED
# define _XOPEN_SOURCE_EXTENDED 1
# undef  _LARGEFILE64_SOURCE
# define _LARGEFILE64_SOURCE    1
# undef  _BSD_SOURCE
# define _BSD_SOURCE    1
# undef  _SVID_SOURCE
# define _SVID_SOURCE   1
# undef  _ATFILE_SOURCE
# define _ATFILE_SOURCE 1
#endif

This is not fine-grained control of what libc exports. This is "if you  
want to use unshare() then everything we ever implemented gets  
simultaneously exported into your namespace". (Which it _mostly_ is if  
you never use any feature test macros, but not the Linux-specific  
system calls.)

The new musl-libc.org did an _ALL_SOURCE macro that just enables every  
feature test macro they implemented. (That's its definition, it's the  
feature test macro that says feature test macros area bad idea.)

> Although come to think of it I can't imagine how <sched.h> is a POSIX
> header.  Last I looked it only had linux specific bits in it.  Which
> makes needing any kind of #define strange.

My objection is that Linux system calls are not part of the GNU  
project. Requiring that macro to get Linux system calls out of bionic,  
uClibc, klibc, musl, olibc, dietlibc, or newlib is _silly_. It's the  
"GNU/Linux" prefix imposed on the source level, and it's a fairly  
recent development (I've only noticed it since 2008 or so).

Rob

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

On Mon, Mar 4, 2013 at 8:27 PM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> wrote:
> On 03/03/2013 10:03:55 PM, Eric W. Biederman wrote:
>>
>> Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> writes:
>>
>> > On 03/01/2013 03:57:40 AM, Michael Kerrisk (man-pages) wrote:
>> >> > And yet the glibc guys insist on #define
>> >> GNU_GNU_GNU_ALL_HAIL_STALLMAN in
>> >> > order to access this Linux-specific feature which has nothing
>> >> whatsoever to
>> >> > do with the FSF.
>> >>
>> >> This is a misunderstanding. _GNU_SOURCE is the standard way to expose
>> >> Linux-specific functionality from POSIX header files.
>> >
>> > What standard? The Linux kernel is not, and never was, part of the GNU
>> > project.
>>
>> Is the argument that there should be a _LINUX_SOURCE directive in glibc
>> for this?
>
>
> If you don't #define any feature test macros at all, you get a bunch of
> macros (_BSD_SOURCE, _SVID_SOURCE, _POSIX_SOURCE, _POSIX_C_SOURCE=200809L,
> and so on) defined by default in features.h. If you start defining macros,
> several of the default ones _go_away_, and you start missing things that are
> defined by posix-2008. Yes, defining feature test macros makes definitions
> _vanish_ out of the headers, which means feature test macros can actually
> reduce code portability.

This has nothing to do with reducing portability; have a (careful)
read of feature_test_macros(7).

[...]

> The new musl-libc.org did an _ALL_SOURCE macro that just enables every
> feature test macro they implemented. (That's its definition, it's the
> feature test macro that says feature test macros area bad idea.)
>
>
>> Although come to think of it I can't imagine how <sched.h> is a POSIX
>> header.  Last I looked it only had linux specific bits in it.  Which
>> makes needing any kind of #define strange.
>
>
> My objection is that Linux system calls are not part of the GNU project.
> Requiring that macro to get Linux system calls out of bionic, uClibc, klibc,
> musl, olibc, dietlibc, or newlib is _silly_. It's the "GNU/Linux" prefix
> imposed on the source level, and it's a fairly recent development (I've only
> noticed it since 2008 or so).

The macro has been present since at least glibc 2.0 (1997).

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/

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

On Mon, Mar 4, 2013 at 4:50 AM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> wrote:
> On 03/01/2013 03:57:40 AM, Michael Kerrisk (man-pages) wrote:
>>
>> > And yet the glibc guys insist on #define GNU_GNU_GNU_ALL_HAIL_STALLMAN
>> > in
>> > order to access this Linux-specific feature which has nothing whatsoever
>> > to
>> > do with the FSF.
>>
>> This is a misunderstanding. _GNU_SOURCE is the standard way to expose
>> Linux-specific functionality from POSIX header files.
>
>
> What standard? The Linux kernel is not, and never was, part of the GNU
> project.

This is "the standard way that glibc isolates Linux-specific
functionality in POSIX header files".

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>
>> Hi Rob,
>>
>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@landley.net> wrote:
>>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
>> [...]
>>
>>>> DESCRIPTION
>>>>        For an overview of namespaces, see namespaces(7).
>>>>
>>>>        PID  namespaces  isolate  the  process ID number space, meaning
>>>>        that processes in different PID namespaces can  have  the  same
>>>>        PID.
>>>
>>>
>>> Um, perhaps "different processes"? Slightly repetitive, but trying to avoid
>>> the potential misreading that "a processes can have the same PID in
>>> different namespaces". (A single process can't be a member of more than one
>>> namespace. This is not about selective visibility.)
>>
>> I'm not sure this clarifies things...
>>
>>>> PID namespaces allow containers to migrate to a new host
>>>>        while the processes inside  the  container  maintain  the  same
>>>>        PIDs.
>>>
>>>
>>> I thought suspend/resume a container was the simple case. Migration to a new
>>> host is built on top of that. (On resume in a new container on the same
>>> system, if other stuff is going on in the system so the available PIDs have
>>> shifted.)
>>
>> I'll add some words here on suspend/resume.
>>
>>>>        Likewise, a process in an ancestor namespace can—subject to the
>>>>        usual permission checks described in  kill(2)—send  signals  to
>>>>        the  "init" process of a child PID namespace only if the "init"
>>>>        process has established a handler for that signal.  (Within the
>>>>        handler,  the  siginfo_t si_pid field described in sigaction(2)
>>>>        will be zero.)  SIGKILL or SIGSTOP are  treated  exceptionally:
>>>>        these signals are forcibly delivered when sent from an ancestor
>>>>        PID namespace.  Neither of these signals can be caught  by  the
>>>>        "init" process, and so will result in the usual actions associ‐
>>>>        ated with those signals (respectively, terminating and stopping
>>>>        the process).
>>>
>>>
>>> If SIGKILL to init is propogated to all the children of init, is SIGSTOP
>>> also propogated to all the children? (I.E. will SIGSTOP to container's init
>>> suspend the whole container, and will SIGCONT resume the whole container? If
>>> the latter, will it only resume processes that weren't previously stopped?
>>> :)
>>
>> Covered by Eric.
>>
>>>>        To put things another way: a process's PID namespace membership
>>>>        is determined when the process is created and cannot be changed
>>>>        thereafter.  Among other things, this means that  the  parental
>>>>        relationship between processes mirrors the parental between PID
>>>
>>>
>>> mirrors the relationship
>>
>> Thanks.
>>
>>>>        namespaces: the parent of a  process  is  either  in  the  same
>>>>        namespace or resides in the immediate parent PID namespace.
>>>>
>>>>        Every  thread  in  a process must be in the same PID namespace.
>>>>        For this reason, the two following call sequences will fail:
>>>>
>>>>            unshare(CLONE_NEWPID);
>>>>            clone(..., CLONE_VM, ...);    /* Fails */
>>>>
>>>>            setns(fd, CLONE_NEWPID);
>>>>            clone(..., CLONE_VM, ...);    /* Fails */
>>>
>>>
>>> They fail with -EUNDOCUMENTED
>>
>> Added EINVAL, as per Eric's reply. (Eric does that error also apply
>> for the two new cases you added?).
>>
>>>>        Because the above unshare(2) and setns(2) calls only change the
>>>>        PID  namespace  for created children, the clone(2) calls neces‐
>>>>        sarily put the new thread in a different PID namespace from the
>>>>        calling thread.
>>>
>>>
>>> Um, no they don't. They fail. That's the point.
>>
>> (Good catch.)
>>
>>> They _would_ put the new
>>> thread in a different PID namespace, which breaks the definition of threads.
>>>
>>> How about:
>>>
>>> The above unshare(2) and setns(2) calls change the PID namespace of
>>> children created by subsequent clone(2) calls, which is incompatible
>>> with CLONE_VM.
>>
>> I decided on:
>>
>>        The  point  here is that unshare(2) and setns(2) change the PID
>>        namespace for created children but not for the calling process,
>>        while  clone(2) CLONE_VM specifies the creation of a new thread
>>        in the same process.
>
> Can we make that "for all new tasks created" instead of "created
> children"
>
> Othewise someone might expect CLONE_THREAD would work as you
> CLONE_THREAD creates a thread and not a child...

The term "task" is kernel-space talk that rarely appears in man pages,
so I am reluctant to use it.

How about this:

       The  point  here is that unshare(2) and setns(2) change the PID
       namespace for processes subsequently created by the caller, but
       not  for the calling process, while clone(2) CLONE_VM specifies
       the creation of a new thread in the same process.

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

Re: For review: pid_namespaces(7) man page

[Eric W. Biederman]

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>
>>> Hi Rob,
>>>
>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@landley.net> wrote:
>>>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
>>> [...]
>>>
>>>>> DESCRIPTION
>>>>>        For an overview of namespaces, see namespaces(7).
>>>>>
>>>>>        PID  namespaces  isolate  the  process ID number space, meaning
>>>>>        that processes in different PID namespaces can  have  the  same
>>>>>        PID.
>>>>
>>>>
>>>> Um, perhaps "different processes"? Slightly repetitive, but trying to avoid
>>>> the potential misreading that "a processes can have the same PID in
>>>> different namespaces". (A single process can't be a member of more than one
>>>> namespace. This is not about selective visibility.)
>>>
>>> I'm not sure this clarifies things...
>>>
>>>>> PID namespaces allow containers to migrate to a new host
>>>>>        while the processes inside  the  container  maintain  the  same
>>>>>        PIDs.
>>>>
>>>>
>>>> I thought suspend/resume a container was the simple case. Migration to a new
>>>> host is built on top of that. (On resume in a new container on the same
>>>> system, if other stuff is going on in the system so the available PIDs have
>>>> shifted.)
>>>
>>> I'll add some words here on suspend/resume.
>>>
>>>>>        Likewise, a process in an ancestor namespace can—subject to the
>>>>>        usual permission checks described in  kill(2)—send  signals  to
>>>>>        the  "init" process of a child PID namespace only if the "init"
>>>>>        process has established a handler for that signal.  (Within the
>>>>>        handler,  the  siginfo_t si_pid field described in sigaction(2)
>>>>>        will be zero.)  SIGKILL or SIGSTOP are  treated  exceptionally:
>>>>>        these signals are forcibly delivered when sent from an ancestor
>>>>>        PID namespace.  Neither of these signals can be caught  by  the
>>>>>        "init" process, and so will result in the usual actions associ‐
>>>>>        ated with those signals (respectively, terminating and stopping
>>>>>        the process).
>>>>
>>>>
>>>> If SIGKILL to init is propogated to all the children of init, is SIGSTOP
>>>> also propogated to all the children? (I.E. will SIGSTOP to container's init
>>>> suspend the whole container, and will SIGCONT resume the whole container? If
>>>> the latter, will it only resume processes that weren't previously stopped?
>>>> :)
>>>
>>> Covered by Eric.
>>>
>>>>>        To put things another way: a process's PID namespace membership
>>>>>        is determined when the process is created and cannot be changed
>>>>>        thereafter.  Among other things, this means that  the  parental
>>>>>        relationship between processes mirrors the parental between PID
>>>>
>>>>
>>>> mirrors the relationship
>>>
>>> Thanks.
>>>
>>>>>        namespaces: the parent of a  process  is  either  in  the  same
>>>>>        namespace or resides in the immediate parent PID namespace.
>>>>>
>>>>>        Every  thread  in  a process must be in the same PID namespace.
>>>>>        For this reason, the two following call sequences will fail:
>>>>>
>>>>>            unshare(CLONE_NEWPID);
>>>>>            clone(..., CLONE_VM, ...);    /* Fails */
>>>>>
>>>>>            setns(fd, CLONE_NEWPID);
>>>>>            clone(..., CLONE_VM, ...);    /* Fails */
>>>>
>>>>
>>>> They fail with -EUNDOCUMENTED
>>>
>>> Added EINVAL, as per Eric's reply. (Eric does that error also apply
>>> for the two new cases you added?).
>>>
>>>>>        Because the above unshare(2) and setns(2) calls only change the
>>>>>        PID  namespace  for created children, the clone(2) calls neces‐
>>>>>        sarily put the new thread in a different PID namespace from the
>>>>>        calling thread.
>>>>
>>>>
>>>> Um, no they don't. They fail. That's the point.
>>>
>>> (Good catch.)
>>>
>>>> They _would_ put the new
>>>> thread in a different PID namespace, which breaks the definition of threads.
>>>>
>>>> How about:
>>>>
>>>> The above unshare(2) and setns(2) calls change the PID namespace of
>>>> children created by subsequent clone(2) calls, which is incompatible
>>>> with CLONE_VM.
>>>
>>> I decided on:
>>>
>>>        The  point  here is that unshare(2) and setns(2) change the PID
>>>        namespace for created children but not for the calling process,
>>>        while  clone(2) CLONE_VM specifies the creation of a new thread
>>>        in the same process.
>>
>> Can we make that "for all new tasks created" instead of "created
>> children"
>>
>> Othewise someone might expect CLONE_THREAD would work as you
>> CLONE_THREAD creates a thread and not a child...
>
> The term "task" is kernel-space talk that rarely appears in man pages,
> so I am reluctant to use it.

With respect to clone and in this case I am not certain we can properly
describe what happens without talking about tasks.  But it is worth
a try.


> How about this:
>
>        The  point  here is that unshare(2) and setns(2) change the PID
>        namespace for processes subsequently created by the caller, but
>        not  for the calling process, while clone(2) CLONE_VM specifies
>        the creation of a new thread in the same process.

Hmm.  How about this.

         The point here is that unshare(2) and setns(2) change the PID
         namespace that will be used by in all subsequent calls to clone
         and fork by the caller, but not for the calling process, and
         that all threads in a process must share the same PID
         namespace.  Which makes a subsequent clone(2) CLONE_VM
         specify the creation of a new thread in the a different PID
         namespace but in the same process which is impossible.

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

Eric,

On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman <ebiederm@xmission.com>
wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>
>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman <ebiederm@xmission.com>
wrote:
>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>
>>>> Hi Rob,
>>>>
>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@landley.net> wrote:
>>>>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
[...]
>>>>>> Because the above unshare(2) and setns(2) calls only change the
>>>>>> PID namespace for created children, the clone(2) calls neces‐
>>>>>> sarily put the new thread in a different PID namespace from the
>>>>>> calling thread.
>>>>>
>>>>>
>>>>> Um, no they don't. They fail. That's the point.
>>>>
>>>> (Good catch.)
>>>>
>>>>> They _would_ put the new
>>>>> thread in a different PID namespace, which breaks the definition of
threads.
>>>>>
>>>>> How about:
>>>>>
>>>>> The above unshare(2) and setns(2) calls change the PID namespace of
>>>>> children created by subsequent clone(2) calls, which is incompatible
>>>>> with CLONE_VM.
>>>>
>>>> I decided on:
>>>>
>>>> The point here is that unshare(2) and setns(2) change the PID
>>>> namespace for created children but not for the calling process,
>>>> while clone(2) CLONE_VM specifies the creation of a new thread
>>>> in the same process.
>>>
>>> Can we make that "for all new tasks created" instead of "created
>>> children"
>>>
>>> Othewise someone might expect CLONE_THREAD would work as you
>>> CLONE_THREAD creates a thread and not a child...
>>
>> The term "task" is kernel-space talk that rarely appears in man pages,
>> so I am reluctant to use it.
>
> With respect to clone and in this case I am not certain we can properly
> describe what happens without talking about tasks. But it is worth
> a try.
>
>
>> How about this:
>>
>> The point here is that unshare(2) and setns(2) change the PID
>> namespace for processes subsequently created by the caller, but
>> not for the calling process, while clone(2) CLONE_VM specifies
>> the creation of a new thread in the same process.
>
> Hmm. How about this.
>
> The point here is that unshare(2) and setns(2) change the PID
> namespace that will be used by in all subsequent calls to clone
> and fork by the caller, but not for the calling process, and
> that all threads in a process must share the same PID
> namespace. Which makes a subsequent clone(2) CLONE_VM
> specify the creation of a new thread in the a different PID
> namespace but in the same process which is impossible.

I did a little tidying:

The point here is that unshare(2) and setns(2) change the
PID namespace that will be used in all subsequent calls
to clone(2) and fork(2), but do not change the PID names‐
pace of the calling process. Because a subsequent
clone(2) CLONE_VM would imply the creation of a new
thread in a different PID namespace, the operation is not
permitted.

Okay?

Having asked that, I realize that I'm still not quite comfortable with this
text. I think the problem is really one of terminology. At the start of
this passage in the page, there is the sentence:

Every thread in a process must be in the
same PID namespace.

Can you define "thread" in this context?

Thanks,

Michael
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

[Resending, since my mobile device turned things into HTML]

Eric,

On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>
>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>
>>>> Hi Rob,
>>>>
>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@landley.net> wrote:
>>>>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
[...]
>>>>>> Because the above unshare(2) and setns(2) calls only change the
>>>>>> PID namespace for created children, the clone(2) calls neces‐
>>>>>> sarily put the new thread in a different PID namespace from the
>>>>>> calling thread.
>>>>>
>>>>>
>>>>> Um, no they don't. They fail. That's the point.
>>>>
>>>> (Good catch.)
>>>>
>>>>> They _would_ put the new
>>>>> thread in a different PID namespace, which breaks the definition of threads.
>>>>>
>>>>> How about:
>>>>>
>>>>> The above unshare(2) and setns(2) calls change the PID namespace of
>>>>> children created by subsequent clone(2) calls, which is incompatible
>>>>> with CLONE_VM.
>>>>
>>>> I decided on:
>>>>
>>>> The point here is that unshare(2) and setns(2) change the PID
>>>> namespace for created children but not for the calling process,
>>>> while clone(2) CLONE_VM specifies the creation of a new thread
>>>> in the same process.
>>>
>>> Can we make that "for all new tasks created" instead of "created
>>> children"
>>>
>>> Othewise someone might expect CLONE_THREAD would work as you
>>> CLONE_THREAD creates a thread and not a child...
>>
>> The term "task" is kernel-space talk that rarely appears in man pages,
>> so I am reluctant to use it.
>
> With respect to clone and in this case I am not certain we can properly
> describe what happens without talking about tasks. But it is worth
> a try.
>
>
>> How about this:
>>
>> The point here is that unshare(2) and setns(2) change the PID
>> namespace for processes subsequently created by the caller, but
>> not for the calling process, while clone(2) CLONE_VM specifies
>> the creation of a new thread in the same process.
>
> Hmm. How about this.
>
> The point here is that unshare(2) and setns(2) change the PID
> namespace that will be used by in all subsequent calls to clone
> and fork by the caller, but not for the calling process, and
> that all threads in a process must share the same PID
> namespace. Which makes a subsequent clone(2) CLONE_VM
> specify the creation of a new thread in the a different PID
> namespace but in the same process which is impossible.

I did a little tidying:

The point here is that unshare(2) and setns(2) change the
PID namespace that will be used in all subsequent calls
to clone(2) and fork(2), but do not change the PID names‐
pace of the calling process. Because a subsequent
clone(2) CLONE_VM would imply the creation of a new
thread in a different PID namespace, the operation is not
permitted.

Okay?

Having asked that, I realize that I'm still not quite comfortable with
this text. I think the problem is really one of terminology. At the
start of this passage in the page, there is the sentence:

Every thread in a process must be in the
same PID namespace.

Can you define "thread" in this context?

Thanks,

Michael
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: For review: pid_namespaces(7) man page

[Eric W. Biederman]

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

> Eric,
>
> On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>
>>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>>
>>>>> Hi Rob,
>>>>>
>>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@landley.net>
> wrote:
>>>>>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
> [...]
>>>>>>> Because the above unshare(2) and setns(2) calls only change the
>>>>>>> PID namespace for created children, the clone(2) calls neces‐
>>>>>>> sarily put the new thread in a different PID namespace from the
>>>>>>> calling thread.
>>>>>>
>>>>>>
>>>>>> Um, no they don't. They fail. That's the point.
>>>>>
>>>>> (Good catch.)
>>>>>
>>>>>> They _would_ put the new
>>>>>> thread in a different PID namespace, which breaks the definition
> of threads.
>>>>>>
>>>>>> How about:
>>>>>>
>>>>>> The above unshare(2) and setns(2) calls change the PID namespace
> of
>>>>>> children created by subsequent clone(2) calls, which is
> incompatible
>>>>>> with CLONE_VM.
>>>>>
>>>>> I decided on:
>>>>>
>>>>> The point here is that unshare(2) and setns(2) change the PID
>>>>> namespace for created children but not for the calling process,
>>>>> while clone(2) CLONE_VM specifies the creation of a new thread
>>>>> in the same process.
>>>>
>>>> Can we make that "for all new tasks created" instead of "created
>>>> children"
>>>>
>>>> Othewise someone might expect CLONE_THREAD would work as you
>>>> CLONE_THREAD creates a thread and not a child...
>>>
>>> The term "task" is kernel-space talk that rarely appears in man
> pages,
>>> so I am reluctant to use it.
>>
>> With respect to clone and in this case I am not certain we can
> properly
>> describe what happens without talking about tasks. But it is worth
>> a try.
>>
>>
>>> How about this:
>>>
>>> The point here is that unshare(2) and setns(2) change the PID
>>> namespace for processes subsequently created by the caller, but
>>> not for the calling process, while clone(2) CLONE_VM specifies
>>> the creation of a new thread in the same process.
>>
>> Hmm. How about this.
>>
>> The point here is that unshare(2) and setns(2) change the PID
>> namespace that will be used by in all subsequent calls to clone
>> and fork by the caller, but not for the calling process, and
>> that all threads in a process must share the same PID
>> namespace. Which makes a subsequent clone(2) CLONE_VM
>> specify the creation of a new thread in the a different PID
>> namespace but in the same process which is impossible.
>
> I did a little tidying:
>
> The point here is that unshare(2) and setns(2) change the
> PID namespace that will be used in all subsequent calls
> to clone(2) and fork(2), but do not change the PID names‐
> pace of the calling process. Because a subsequent
> clone(2) CLONE_VM would imply the creation of a new
> thread in a different PID namespace, the operation is not
> permitted.
>
> Okay?

That seems reasonable.

CLONE_THREAD might be better to talk about.  The check is CLONE_VM
because it is easier and CLONE_THREAD implies CLONE_THREAD.

> Having asked that, I realize that I'm still not quite comfortable with
> this text. I think the problem is really one of terminology. At the
> start of this passage in the page, there is the sentence:
>
> Every thread in a process must be in the 
> same PID namespace.
>
> Can you define "thread" in this context?

Most definitely a thread group created with CLONE_THREAD.  It is pretty
ugly in just the old fashioned CLONE_VM case too, but that might be
legal.

In a few cases I think the implementation overshoots and test for VM
sharing instead of thread group membership because VM sharing is easier
to test for, and we already have tests for that.

Eric

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

On Tue, Mar 5, 2013 at 7:41 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>
>> Eric,
>>
>> On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>
>>>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>>>
>>>>>> Hi Rob,
>>>>>>
>>>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@landley.net>
>> wrote:
>>>>>>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
>> [...]
>>>>>>>> Because the above unshare(2) and setns(2) calls only change the
>>>>>>>> PID namespace for created children, the clone(2) calls neces‐
>>>>>>>> sarily put the new thread in a different PID namespace from the
>>>>>>>> calling thread.
>>>>>>>
>>>>>>>
>>>>>>> Um, no they don't. They fail. That's the point.
>>>>>>
>>>>>> (Good catch.)
>>>>>>
>>>>>>> They _would_ put the new
>>>>>>> thread in a different PID namespace, which breaks the definition
>> of threads.
>>>>>>>
>>>>>>> How about:
>>>>>>>
>>>>>>> The above unshare(2) and setns(2) calls change the PID namespace
>> of
>>>>>>> children created by subsequent clone(2) calls, which is
>> incompatible
>>>>>>> with CLONE_VM.
>>>>>>
>>>>>> I decided on:
>>>>>>
>>>>>> The point here is that unshare(2) and setns(2) change the PID
>>>>>> namespace for created children but not for the calling process,
>>>>>> while clone(2) CLONE_VM specifies the creation of a new thread
>>>>>> in the same process.
>>>>>
>>>>> Can we make that "for all new tasks created" instead of "created
>>>>> children"
>>>>>
>>>>> Othewise someone might expect CLONE_THREAD would work as you
>>>>> CLONE_THREAD creates a thread and not a child...
>>>>
>>>> The term "task" is kernel-space talk that rarely appears in man
>> pages,
>>>> so I am reluctant to use it.
>>>
>>> With respect to clone and in this case I am not certain we can
>> properly
>>> describe what happens without talking about tasks. But it is worth
>>> a try.
>>>
>>>
>>>> How about this:
>>>>
>>>> The point here is that unshare(2) and setns(2) change the PID
>>>> namespace for processes subsequently created by the caller, but
>>>> not for the calling process, while clone(2) CLONE_VM specifies
>>>> the creation of a new thread in the same process.
>>>
>>> Hmm. How about this.
>>>
>>> The point here is that unshare(2) and setns(2) change the PID
>>> namespace that will be used by in all subsequent calls to clone
>>> and fork by the caller, but not for the calling process, and
>>> that all threads in a process must share the same PID
>>> namespace. Which makes a subsequent clone(2) CLONE_VM
>>> specify the creation of a new thread in the a different PID
>>> namespace but in the same process which is impossible.
>>
>> I did a little tidying:
>>
>> The point here is that unshare(2) and setns(2) change the
>> PID namespace that will be used in all subsequent calls
>> to clone(2) and fork(2), but do not change the PID names‐
>> pace of the calling process. Because a subsequent
>> clone(2) CLONE_VM would imply the creation of a new
>> thread in a different PID namespace, the operation is not
>> permitted.
>>
>> Okay?
>
> That seems reasonable.
>
> CLONE_THREAD might be better to talk about.  The check is CLONE_VM
> because it is easier and CLONE_THREAD implies CLONE_THREAD.
>
>> Having asked that, I realize that I'm still not quite comfortable with
>> this text. I think the problem is really one of terminology. At the
>> start of this passage in the page, there is the sentence:
>>
>> Every thread in a process must be in the
>> same PID namespace.
>>
>> Can you define "thread" in this context?
>
> Most definitely a thread group created with CLONE_THREAD.  It is pretty
> ugly in just the old fashioned CLONE_VM case too, but that might be
> legal.
>
> In a few cases I think the implementation overshoots and test for VM
> sharing instead of thread group membership because VM sharing is easier
> to test for, and we already have tests for that.

So, in summary, the point is that CLONE_VM is being used as a proxy
for CLONE_THREAD because the former is easier to test for, and
CLONE_THREAD requires CLONE_VM, right?

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

Re: For review: pid_namespaces(7) man page

[Eric W. Biederman]

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

> On Tue, Mar 5, 2013 at 7:41 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>
>>> Eric,
>>>
>>> On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman
>>> <ebiederm@xmission.com> wrote:
>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>>
>>>>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman
>>> <ebiederm@xmission.com> wrote:
>>>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>>>>
>>>>>>> Hi Rob,
>>>>>>>
>>>>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@landley.net>
>>> wrote:
>>>>>>>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
>>> [...]
>>>>>>>>> Because the above unshare(2) and setns(2) calls only change the
>>>>>>>>> PID namespace for created children, the clone(2) calls neces‐
>>>>>>>>> sarily put the new thread in a different PID namespace from the
>>>>>>>>> calling thread.
>>>>>>>>
>>>>>>>>
>>>>>>>> Um, no they don't. They fail. That's the point.
>>>>>>>
>>>>>>> (Good catch.)
>>>>>>>
>>>>>>>> They _would_ put the new
>>>>>>>> thread in a different PID namespace, which breaks the definition
>>> of threads.
>>>>>>>>
>>>>>>>> How about:
>>>>>>>>
>>>>>>>> The above unshare(2) and setns(2) calls change the PID namespace
>>> of
>>>>>>>> children created by subsequent clone(2) calls, which is
>>> incompatible
>>>>>>>> with CLONE_VM.
>>>>>>>
>>>>>>> I decided on:
>>>>>>>
>>>>>>> The point here is that unshare(2) and setns(2) change the PID
>>>>>>> namespace for created children but not for the calling process,
>>>>>>> while clone(2) CLONE_VM specifies the creation of a new thread
>>>>>>> in the same process.
>>>>>>
>>>>>> Can we make that "for all new tasks created" instead of "created
>>>>>> children"
>>>>>>
>>>>>> Othewise someone might expect CLONE_THREAD would work as you
>>>>>> CLONE_THREAD creates a thread and not a child...
>>>>>
>>>>> The term "task" is kernel-space talk that rarely appears in man
>>> pages,
>>>>> so I am reluctant to use it.
>>>>
>>>> With respect to clone and in this case I am not certain we can
>>> properly
>>>> describe what happens without talking about tasks. But it is worth
>>>> a try.
>>>>
>>>>
>>>>> How about this:
>>>>>
>>>>> The point here is that unshare(2) and setns(2) change the PID
>>>>> namespace for processes subsequently created by the caller, but
>>>>> not for the calling process, while clone(2) CLONE_VM specifies
>>>>> the creation of a new thread in the same process.
>>>>
>>>> Hmm. How about this.
>>>>
>>>> The point here is that unshare(2) and setns(2) change the PID
>>>> namespace that will be used by in all subsequent calls to clone
>>>> and fork by the caller, but not for the calling process, and
>>>> that all threads in a process must share the same PID
>>>> namespace. Which makes a subsequent clone(2) CLONE_VM
>>>> specify the creation of a new thread in the a different PID
>>>> namespace but in the same process which is impossible.
>>>
>>> I did a little tidying:
>>>
>>> The point here is that unshare(2) and setns(2) change the
>>> PID namespace that will be used in all subsequent calls
>>> to clone(2) and fork(2), but do not change the PID names‐
>>> pace of the calling process. Because a subsequent
>>> clone(2) CLONE_VM would imply the creation of a new
>>> thread in a different PID namespace, the operation is not
>>> permitted.
>>>
>>> Okay?
>>
>> That seems reasonable.
>>
>> CLONE_THREAD might be better to talk about.  The check is CLONE_VM
>> because it is easier and CLONE_THREAD implies CLONE_THREAD.
>>
>>> Having asked that, I realize that I'm still not quite comfortable with
>>> this text. I think the problem is really one of terminology. At the
>>> start of this passage in the page, there is the sentence:
>>>
>>> Every thread in a process must be in the
>>> same PID namespace.
>>>
>>> Can you define "thread" in this context?
>>
>> Most definitely a thread group created with CLONE_THREAD.  It is pretty
>> ugly in just the old fashioned CLONE_VM case too, but that might be
>> legal.
>>
>> In a few cases I think the implementation overshoots and test for VM
>> sharing instead of thread group membership because VM sharing is easier
>> to test for, and we already have tests for that.
>
> So, in summary, the point is that CLONE_VM is being used as a proxy
> for CLONE_THREAD because the former is easier to test for, and
> CLONE_THREAD requires CLONE_VM, right?

I am totally lost about what we are problem we are trying to resolve in
the text at this point.  So I am taking this opportunity to review
what is actually happening and hopefully give a clear and useful
explanation.

The clone flags have some dependencies.
CLONE_SIGHAND requires CLONE_VM.
CLONE_THREAD requires CLONE_SIGHAND.

Ultimately there are cases in here that are too strange to think about,
and that no one cares (except so far to document what is going on).  The
fundamental goal of these checks it to just not allow the cases that
are too strange to think about.

From a technical point of view CLONE_THREAD requires being in the same
PID namespace so you can send signals to other threads in your process,
and you need to see in proc all of the threads of your process.

From a technical point of view CLONE_SIGHAND requries being in the same
PID namespace because we need to know how to encode the PID of the
sending process at the time a signal is enqueued in the destination
queue.  A signal queue shared by processes in multiple PID namespaces
will defeat that.

From a technical point of view CLONE_VM requires all of the threads to
be in a PID namespace, because from the point of view of coredump code
if two processes share the same address space they are threads and will
be core dumped together.  When a coredump is written the pid of each
thread is written into the coredump.  Writing the pids could not
meaningfully succeed if some of the pids were in a parent PID namespace.

Therefore there is a technical requirement for each of CLONE_THREAD,
CLONE_SIGHAND, CLONE_VM to share a PID namespace.

In the code in the kernel testing only for CLONE_VM is a shorthand for
testing for any of CLONE_THREAD, CLONE_SIGHAND, or CLONE_VM.



On the flip side the addition by unshare(CLONE_NEWPID) of
unshare(CLONE_THREAD) actually appears to be bogus because we do not
change the pid namespace of the process calling unshare (only it's
children), and we already allow that case with setns.  I need to think
about that case a little more but I am going to queue up a patch for
3.10 to make unshare(CLONE_NEWPID) and setns(CLONE_NEWPID) consistent.
Probably by removing the check in unshare(CLONE_NEWPID).

I need to think about a bit about what happens from the threaded parents
perspective when different threads can create children in different PID
namespaces. Does it introduce weird hard to support cases into the code?
Or will it just work without requiring anything special and I can allow
it.

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

On Wed, Mar 6, 2013 at 1:40 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>
>> On Tue, Mar 5, 2013 at 7:41 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>
>>>> Eric,
>>>>
>>>> On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman
>>>> <ebiederm@xmission.com> wrote:
>>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>>>
>>>>>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman
>>>> <ebiederm@xmission.com> wrote:
>>>>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>>>>>
>>>>>>>> Hi Rob,
>>>>>>>>
>>>>>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@landley.net>
>>>> wrote:
>>>>>>>>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
>>>> [...]
>>>>>>>>>> Because the above unshare(2) and setns(2) calls only change the
>>>>>>>>>> PID namespace for created children, the clone(2) calls neces‐
>>>>>>>>>> sarily put the new thread in a different PID namespace from the
>>>>>>>>>> calling thread.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Um, no they don't. They fail. That's the point.
>>>>>>>>
>>>>>>>> (Good catch.)
>>>>>>>>
>>>>>>>>> They _would_ put the new
>>>>>>>>> thread in a different PID namespace, which breaks the definition
>>>> of threads.
>>>>>>>>>
>>>>>>>>> How about:
>>>>>>>>>
>>>>>>>>> The above unshare(2) and setns(2) calls change the PID namespace
>>>> of
>>>>>>>>> children created by subsequent clone(2) calls, which is
>>>> incompatible
>>>>>>>>> with CLONE_VM.
>>>>>>>>
>>>>>>>> I decided on:
>>>>>>>>
>>>>>>>> The point here is that unshare(2) and setns(2) change the PID
>>>>>>>> namespace for created children but not for the calling process,
>>>>>>>> while clone(2) CLONE_VM specifies the creation of a new thread
>>>>>>>> in the same process.
>>>>>>>
>>>>>>> Can we make that "for all new tasks created" instead of "created
>>>>>>> children"
>>>>>>>
>>>>>>> Othewise someone might expect CLONE_THREAD would work as you
>>>>>>> CLONE_THREAD creates a thread and not a child...
>>>>>>
>>>>>> The term "task" is kernel-space talk that rarely appears in man
>>>> pages,
>>>>>> so I am reluctant to use it.
>>>>>
>>>>> With respect to clone and in this case I am not certain we can
>>>> properly
>>>>> describe what happens without talking about tasks. But it is worth
>>>>> a try.
>>>>>
>>>>>
>>>>>> How about this:
>>>>>>
>>>>>> The point here is that unshare(2) and setns(2) change the PID
>>>>>> namespace for processes subsequently created by the caller, but
>>>>>> not for the calling process, while clone(2) CLONE_VM specifies
>>>>>> the creation of a new thread in the same process.
>>>>>
>>>>> Hmm. How about this.
>>>>>
>>>>> The point here is that unshare(2) and setns(2) change the PID
>>>>> namespace that will be used by in all subsequent calls to clone
>>>>> and fork by the caller, but not for the calling process, and
>>>>> that all threads in a process must share the same PID
>>>>> namespace. Which makes a subsequent clone(2) CLONE_VM
>>>>> specify the creation of a new thread in the a different PID
>>>>> namespace but in the same process which is impossible.
>>>>
>>>> I did a little tidying:
>>>>
>>>> The point here is that unshare(2) and setns(2) change the
>>>> PID namespace that will be used in all subsequent calls
>>>> to clone(2) and fork(2), but do not change the PID names‐
>>>> pace of the calling process. Because a subsequent
>>>> clone(2) CLONE_VM would imply the creation of a new
>>>> thread in a different PID namespace, the operation is not
>>>> permitted.
>>>>
>>>> Okay?
>>>
>>> That seems reasonable.
>>>
>>> CLONE_THREAD might be better to talk about.  The check is CLONE_VM
>>> because it is easier and CLONE_THREAD implies CLONE_THREAD.
>>>
>>>> Having asked that, I realize that I'm still not quite comfortable with
>>>> this text. I think the problem is really one of terminology. At the
>>>> start of this passage in the page, there is the sentence:
>>>>
>>>> Every thread in a process must be in the
>>>> same PID namespace.
>>>>
>>>> Can you define "thread" in this context?
>>>
>>> Most definitely a thread group created with CLONE_THREAD.  It is pretty
>>> ugly in just the old fashioned CLONE_VM case too, but that might be
>>> legal.
>>>
>>> In a few cases I think the implementation overshoots and test for VM
>>> sharing instead of thread group membership because VM sharing is easier
>>> to test for, and we already have tests for that.
>>
>> So, in summary, the point is that CLONE_VM is being used as a proxy
>> for CLONE_THREAD because the former is easier to test for, and
>> CLONE_THREAD requires CLONE_VM, right?
>
> I am totally lost about what we are problem we are trying to resolve in
> the text at this point.  So I am taking this opportunity to review
> what is actually happening and hopefully give a clear and useful
> explanation.

The problem is that the existing text talks about multithreaded
processes needing to be in the same PID namespace and then jumps to
talking about restrictions with CLONE_VM (not CLONE_THREAD). The
reader may not realize know that CLONE_VM is a near synonym for
"multithreaded process".

However, the text you provide here is wonderful detail:

> The clone flags have some dependencies.
> CLONE_SIGHAND requires CLONE_VM.
> CLONE_THREAD requires CLONE_SIGHAND.
>
> Ultimately there are cases in here that are too strange to think about,
> and that no one cares (except so far to document what is going on).  The
> fundamental goal of these checks it to just not allow the cases that
> are too strange to think about.
>
> From a technical point of view CLONE_THREAD requires being in the same
> PID namespace so you can send signals to other threads in your process,
> and you need to see in proc all of the threads of your process.
>
> From a technical point of view CLONE_SIGHAND requries being in the same
> PID namespace because we need to know how to encode the PID of the
> sending process at the time a signal is enqueued in the destination
> queue.  A signal queue shared by processes in multiple PID namespaces
> will defeat that.
>
> From a technical point of view CLONE_VM requires all of the threads to
> be in a PID namespace, because from the point of view of coredump code
> if two processes share the same address space they are threads and will
> be core dumped together.  When a coredump is written the pid of each
> thread is written into the coredump.  Writing the pids could not
> meaningfully succeed if some of the pids were in a parent PID namespace.
>
> Therefore there is a technical requirement for each of CLONE_THREAD,
> CLONE_SIGHAND, CLONE_VM to share a PID namespace.
>
> In the code in the kernel testing only for CLONE_VM is a shorthand for
> testing for any of CLONE_THREAD, CLONE_SIGHAND, or CLONE_VM.

I will incorporate most of the above into the page.

> On the flip side the addition by unshare(CLONE_NEWPID) of
> unshare(CLONE_THREAD) actually appears to be bogus

I agree that it seems strange.

Cheers,

Michael

> because we do not
> change the pid namespace of the process calling unshare (only it's
> children), and we already allow that case with setns.  I need to think
> about that case a little more but I am going to queue up a patch for
> 3.10 to make unshare(CLONE_NEWPID) and setns(CLONE_NEWPID) consistent.
> Probably by removing the check in unshare(CLONE_NEWPID).
>
> I need to think about a bit about what happens from the threaded parents
> perspective when different threads can create children in different PID
> namespaces. Does it introduce weird hard to support cases into the code?
> Or will it just work without requiring anything special and I can allow
> it.
>
> Eric



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

Re: For review: pid_namespaces(7) man page

[Eric W. Biederman]

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

> On Wed, Mar 6, 2013 at 1:40 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>
>>> On Tue, Mar 5, 2013 at 7:41 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>>
>>>>> Eric,
>>>>>
>>>>> On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman
>>>>> <ebiederm@xmission.com> wrote:
>>>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>>>>
>>>>>>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman
>>>>> <ebiederm@xmission.com> wrote:
>>>>>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>>>>>>
>>>>>>>>> Hi Rob,
>>>>>>>>>
>>>>>>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@landley.net>
>>>>> wrote:
>>>>>>>>>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
>>>>> [...]
>>>>>>>>>>> Because the above unshare(2) and setns(2) calls only change the
>>>>>>>>>>> PID namespace for created children, the clone(2) calls neces‐
>>>>>>>>>>> sarily put the new thread in a different PID namespace from the
>>>>>>>>>>> calling thread.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Um, no they don't. They fail. That's the point.
>>>>>>>>>
>>>>>>>>> (Good catch.)
>>>>>>>>>
>>>>>>>>>> They _would_ put the new
>>>>>>>>>> thread in a different PID namespace, which breaks the definition
>>>>> of threads.
>>>>>>>>>>
>>>>>>>>>> How about:
>>>>>>>>>>
>>>>>>>>>> The above unshare(2) and setns(2) calls change the PID namespace
>>>>> of
>>>>>>>>>> children created by subsequent clone(2) calls, which is
>>>>> incompatible
>>>>>>>>>> with CLONE_VM.
>>>>>>>>>
>>>>>>>>> I decided on:
>>>>>>>>>
>>>>>>>>> The point here is that unshare(2) and setns(2) change the PID
>>>>>>>>> namespace for created children but not for the calling process,
>>>>>>>>> while clone(2) CLONE_VM specifies the creation of a new thread
>>>>>>>>> in the same process.
>>>>>>>>
>>>>>>>> Can we make that "for all new tasks created" instead of "created
>>>>>>>> children"
>>>>>>>>
>>>>>>>> Othewise someone might expect CLONE_THREAD would work as you
>>>>>>>> CLONE_THREAD creates a thread and not a child...
>>>>>>>
>>>>>>> The term "task" is kernel-space talk that rarely appears in man
>>>>> pages,
>>>>>>> so I am reluctant to use it.
>>>>>>
>>>>>> With respect to clone and in this case I am not certain we can
>>>>> properly
>>>>>> describe what happens without talking about tasks. But it is worth
>>>>>> a try.
>>>>>>
>>>>>>
>>>>>>> How about this:
>>>>>>>
>>>>>>> The point here is that unshare(2) and setns(2) change the PID
>>>>>>> namespace for processes subsequently created by the caller, but
>>>>>>> not for the calling process, while clone(2) CLONE_VM specifies
>>>>>>> the creation of a new thread in the same process.
>>>>>>
>>>>>> Hmm. How about this.
>>>>>>
>>>>>> The point here is that unshare(2) and setns(2) change the PID
>>>>>> namespace that will be used by in all subsequent calls to clone
>>>>>> and fork by the caller, but not for the calling process, and
>>>>>> that all threads in a process must share the same PID
>>>>>> namespace. Which makes a subsequent clone(2) CLONE_VM
>>>>>> specify the creation of a new thread in the a different PID
>>>>>> namespace but in the same process which is impossible.
>>>>>
>>>>> I did a little tidying:
>>>>>
>>>>> The point here is that unshare(2) and setns(2) change the
>>>>> PID namespace that will be used in all subsequent calls
>>>>> to clone(2) and fork(2), but do not change the PID names‐
>>>>> pace of the calling process. Because a subsequent
>>>>> clone(2) CLONE_VM would imply the creation of a new
>>>>> thread in a different PID namespace, the operation is not
>>>>> permitted.
>>>>>
>>>>> Okay?
>>>>
>>>> That seems reasonable.
>>>>
>>>> CLONE_THREAD might be better to talk about.  The check is CLONE_VM
>>>> because it is easier and CLONE_THREAD implies CLONE_THREAD.
>>>>
>>>>> Having asked that, I realize that I'm still not quite comfortable with
>>>>> this text. I think the problem is really one of terminology. At the
>>>>> start of this passage in the page, there is the sentence:
>>>>>
>>>>> Every thread in a process must be in the
>>>>> same PID namespace.
>>>>>
>>>>> Can you define "thread" in this context?
>>>>
>>>> Most definitely a thread group created with CLONE_THREAD.  It is pretty
>>>> ugly in just the old fashioned CLONE_VM case too, but that might be
>>>> legal.
>>>>
>>>> In a few cases I think the implementation overshoots and test for VM
>>>> sharing instead of thread group membership because VM sharing is easier
>>>> to test for, and we already have tests for that.
>>>
>>> So, in summary, the point is that CLONE_VM is being used as a proxy
>>> for CLONE_THREAD because the former is easier to test for, and
>>> CLONE_THREAD requires CLONE_VM, right?
>>
>> I am totally lost about what we are problem we are trying to resolve in
>> the text at this point.  So I am taking this opportunity to review
>> what is actually happening and hopefully give a clear and useful
>> explanation.
>
> The problem is that the existing text talks about multithreaded
> processes needing to be in the same PID namespace and then jumps to
> talking about restrictions with CLONE_VM (not CLONE_THREAD). The
> reader may not realize know that CLONE_VM is a near synonym for
> "multithreaded process".
>
> However, the text you provide here is wonderful detail:
>
>> The clone flags have some dependencies.
>> CLONE_SIGHAND requires CLONE_VM.
>> CLONE_THREAD requires CLONE_SIGHAND.
>>
>> Ultimately there are cases in here that are too strange to think about,
>> and that no one cares (except so far to document what is going on).  The
>> fundamental goal of these checks it to just not allow the cases that
>> are too strange to think about.
>>
>> From a technical point of view CLONE_THREAD requires being in the same
>> PID namespace so you can send signals to other threads in your process,
>> and you need to see in proc all of the threads of your process.
>>
>> From a technical point of view CLONE_SIGHAND requries being in the same
>> PID namespace because we need to know how to encode the PID of the
>> sending process at the time a signal is enqueued in the destination
>> queue.  A signal queue shared by processes in multiple PID namespaces
>> will defeat that.
>>
>> From a technical point of view CLONE_VM requires all of the threads to
>> be in a PID namespace, because from the point of view of coredump code
>> if two processes share the same address space they are threads and will
>> be core dumped together.  When a coredump is written the pid of each
>> thread is written into the coredump.  Writing the pids could not
>> meaningfully succeed if some of the pids were in a parent PID namespace.
>>
>> Therefore there is a technical requirement for each of CLONE_THREAD,
>> CLONE_SIGHAND, CLONE_VM to share a PID namespace.
>>
>> In the code in the kernel testing only for CLONE_VM is a shorthand for
>> testing for any of CLONE_THREAD, CLONE_SIGHAND, or CLONE_VM.
>
> I will incorporate most of the above into the page.
>
>> On the flip side the addition by unshare(CLONE_NEWPID) of
>> unshare(CLONE_THREAD) actually appears to be bogus
>
> I agree that it seems strange.

Having looked at it a little more I will be removing the unnecessary
CLONE_THREAD check in 3.10.

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: For review: pid_namespaces(7) man page

[Rob Landley]

On 03/04/2013 11:52:19 AM, Eric W. Biederman wrote:
> > How about this:
> >
> >        The  point  here is that unshare(2) and setns(2) change the  
> PID
> >        namespace for processes subsequently created by the caller,  
> but
> >        not  for the calling process, while clone(2) CLONE_VM  
> specifies
> >        the creation of a new thread in the same process.
> 
> Hmm.  How about this.
> 
>          The point here is that unshare(2) and setns(2) change the PID
>          namespace that will be used by in all subsequent calls to  
> clone
>          and fork by the caller, but not for the calling process, and
>          that all threads in a process must share the same PID
>          namespace.  Which makes a subsequent clone(2) CLONE_VM
>          specify the creation of a new thread in the a different PID
>          namespace but in the same process which is impossible.

CLONE_VM and CLONE_NEWPID are incompatible because all threads of the  
same process must be in the same PID namespace. Since unshare(2) and  
setns(2) change the PID namespace for subsequent calls to clone(2),  
those subsequent calls cannot create new threads (unless you setns(2)  
back to the original namespace first).

That last bit's a guess. :)

Rob

Re: For review: pid_namespaces(7) man page

[Eric W. Biederman]

Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> writes:

> On 03/04/2013 11:52:19 AM, Eric W. Biederman wrote:
>> > How about this:
>> >
>> >        The  point  here is that unshare(2) and setns(2) change the  
>> PID
>> >        namespace for processes subsequently created by the caller,  
>> but
>> >        not  for the calling process, while clone(2) CLONE_VM  
>> specifies
>> >        the creation of a new thread in the same process.
>> 
>> Hmm.  How about this.
>> 
>>          The point here is that unshare(2) and setns(2) change the PID
>>          namespace that will be used by in all subsequent calls to  
>> clone
>>          and fork by the caller, but not for the calling process, and
>>          that all threads in a process must share the same PID
>>          namespace.  Which makes a subsequent clone(2) CLONE_VM
>>          specify the creation of a new thread in the a different PID
>>          namespace but in the same process which is impossible.
>
> CLONE_VM and CLONE_NEWPID are incompatible because all threads of the  
> same process must be in the same PID namespace. Since unshare(2) and  
> setns(2) change the PID namespace for subsequent calls to clone(2),  
> those subsequent calls cannot create new threads (unless you setns(2)  
> back to the original namespace first).
>
> That last bit's a guess. :)

Good wording thank you, and the last bit is right.  You can restore
the pid namespace  with setns(2), and that will allow thread and process
creation creation again.

Eric

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

[CC += Lennart]

On Thu, Feb 28, 2013 at 3:24 PM, Vasily Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org> wrote:
> Hi Michael,
>
> On Thu, Feb 28, 2013 at 12:24 +0100, Michael Kerrisk (man-pages) wrote:
>>    The namespace init process
>>        The first process created in a new namespace (i.e., the process
>>        created using clone(2) with the CLONE_NEWPID flag, or the first
>>        child created by a process after a call to unshare(2) using the
>>        CLONE_NEWPID flag) has the PID 1, and is the "init" process for
>>        the namespace (see init(1)).  Children that are orphaned within
>>        the namespace will be reparented to this  process  rather  than
>>        init(1).
>
> Probably it worth noting here that this is true unless
> prctl() with PR_SET_CHILD_SUBREAPER option is called.

Thanks Vasily. It probably is worth mentioning that, and I will add some words.

One thing I am not sure of (have not tested), but maybe you (or Eric)
know the answer: does the effect of PR_SET_CHILD_SUBREAPER  cross a
PID namespace boundary? In other words, if it was a process in the
parent PID namespace that employed PR_SET_CHILD_SUBREAPER , will that
affect child processes in a child PID namespace, or  wiill
PR_SET_CHILD_SUBREAPER  only apply to child processes in the same PID
namespace as the caller?

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

Re: For review: pid_namespaces(7) man page

[Eric W. Biederman]

"Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> [CC += Lennart]
>
> On Thu, Feb 28, 2013 at 3:24 PM, Vasily Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org> wrote:
>> Hi Michael,
>>
>> On Thu, Feb 28, 2013 at 12:24 +0100, Michael Kerrisk (man-pages) wrote:
>>>    The namespace init process
>>>        The first process created in a new namespace (i.e., the process
>>>        created using clone(2) with the CLONE_NEWPID flag, or the first
>>>        child created by a process after a call to unshare(2) using the
>>>        CLONE_NEWPID flag) has the PID 1, and is the "init" process for
>>>        the namespace (see init(1)).  Children that are orphaned within
>>>        the namespace will be reparented to this  process  rather  than
>>>        init(1).
>>
>> Probably it worth noting here that this is true unless
>> prctl() with PR_SET_CHILD_SUBREAPER option is called.
>
> Thanks Vasily. It probably is worth mentioning that, and I will add some words.
>
> One thing I am not sure of (have not tested), but maybe you (or Eric)
> know the answer: does the effect of PR_SET_CHILD_SUBREAPER  cross a
> PID namespace boundary?

No.

> In other words, if it was a process in the
> parent PID namespace that employed PR_SET_CHILD_SUBREAPER , will that
> affect child processes in a child PID namespace, or  wiill
> PR_SET_CHILD_SUBREAPER  only apply to child processes in the same PID
> namespace as the caller?

With respect to reparenting it acts like an additional pid namespace
init is on the path.

If you want to read the code it is in kernel/exit.c:find_new_reaper().
called from forget_original_parent, which does the actual reparenting.

Eric

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

On Fri, Mar 1, 2013 at 9:36 AM, Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> [CC += Lennart]
>>
>> On Thu, Feb 28, 2013 at 3:24 PM, Vasily Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org> wrote:
>>> Hi Michael,
>>>
>>> On Thu, Feb 28, 2013 at 12:24 +0100, Michael Kerrisk (man-pages) wrote:
>>>>    The namespace init process
>>>>        The first process created in a new namespace (i.e., the process
>>>>        created using clone(2) with the CLONE_NEWPID flag, or the first
>>>>        child created by a process after a call to unshare(2) using the
>>>>        CLONE_NEWPID flag) has the PID 1, and is the "init" process for
>>>>        the namespace (see init(1)).  Children that are orphaned within
>>>>        the namespace will be reparented to this  process  rather  than
>>>>        init(1).
>>>
>>> Probably it worth noting here that this is true unless
>>> prctl() with PR_SET_CHILD_SUBREAPER option is called.
>>
>> Thanks Vasily. It probably is worth mentioning that, and I will add some words.
>>
>> One thing I am not sure of (have not tested), but maybe you (or Eric)
>> know the answer: does the effect of PR_SET_CHILD_SUBREAPER  cross a
>> PID namespace boundary?
>
> No.

Thanks for the clarification, Eric. I'll note that point in the page.

Cheers,

Michael


>> In other words, if it was a process in the
>> parent PID namespace that employed PR_SET_CHILD_SUBREAPER , will that
>> affect child processes in a child PID namespace, or  wiill
>> PR_SET_CHILD_SUBREAPER  only apply to child processes in the same PID
>> namespace as the caller?
>
> With respect to reparenting it acts like an additional pid namespace
> init is on the path.
>
> If you want to read the code it is in kernel/exit.c:find_new_reaper().
> called from forget_original_parent, which does the actual reparenting.
>
> Eric
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

Hi Eric,

On Thu, Feb 28, 2013 at 4:24 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

[...]

>> ==========
>> PID_NAMESPACES(7)      Linux Programmer's Manual     PID_NAMESPACES(7)
>>
>> NAME
>>        pid_namespaces - overview of Linux PID namespaces
>>
>> DESCRIPTION
[...]

>>    The namespace init process
>>        The first process created in a new namespace (i.e., the process
>>        created using clone(2) with the CLONE_NEWPID flag, or the first
>>        child created by a process after a call to unshare(2) using the
>>        CLONE_NEWPID flag) has the PID 1, and is the "init" process for
>>        the namespace (see init(1)).  Children that are orphaned within
>>        the namespace will be reparented to this  process  rather  than
>>        init(1).
>>
>>        If the "init" process of a PID namespace terminates, the kernel
>>        terminates all of the processes in the namespace via a  SIGKILL
>>        signal.   This  behavior  reflects  the  fact  that  the "init"
>>        process is essential for the correct operation of a PID  names‐
>>        pace.   In this case, a subsequent fork(2) into this PID names‐
>>        pace (e.g., from a process that has done a  setns(2)  into  the
>>        namespace    using    an    open    file   descriptor   for   a
>>        /proc/[pid]/ns/pid file corresponding to a process that was  in
>>        the  namespace) will fail with the error ENOMEM; it is not pos‐
>>        sible to create a new processes in a PID namespace whose "init"
>>        process has terminated.
>
> It may be useful to mention unshare in the case of fork(2) failing just
> because that is such an easy mistake to make.
>
> unshare(CLONE_NEWPID);
> pid = fork();
> waitpid(pid,...);
> fork() -> ENOMEM

I'm lost. Why does that sequence fail? The child of fork() becomes PID
1 in the new PID namespace.

>>        Only  signals  for  which  the "init" process has established a
>>        signal handler can be sent to the "init" process by other  mem‐
>>        bers  of  the  PID namespace.  This restriction applies even to
>>        privileged processes, and prevents other  members  of  the  PID
>>        namespace from accidentally killing the "init" process.
>>
>>        Likewise, a process in an ancestor namespace can—subject to the
>>        usual permission checks described in  kill(2)—send  signals  to
>>        the  "init" process of a child PID namespace only if the "init"
>>        process has established a handler for that signal.  (Within the
>>        handler,  the  siginfo_t si_pid field described in sigaction(2)
>>        will be zero.)  SIGKILL or SIGSTOP are  treated  exceptionally:
>>        these signals are forcibly delivered when sent from an ancestor
>>        PID namespace.  Neither of these signals can be caught  by  the
>>        "init" process, and so will result in the usual actions associ‐
>>        ated with those signals (respectively, terminating and stopping
>>        the process).
>>
>>    Nesting PID namespaces
>>        PID  namespaces can be nested: each PID namespace has a parent,
>>        except for the initial ("root") PID namespace.  The parent of a
>>        PID  namespace is the PID namespace of the process that created
>>        the namespace using clone(2)  or  unshare(2).   PID  namespaces
>>        thus  form a tree, with all namespaces ultimately tracing their
>>        ancestry to the root namespace.
>>
>>        A process is visible to other processes in its  PID  namespace,
>>        and  to  the  processes  in  each direct ancestor PID namespace
>>        going back to the root PID namespace.  In this context,  "visi‐
>>        ble"  means that one process can be the target of operations by
>>        another process using system calls that specify a  process  ID.
>>        Conversely,  the  processes  in a child PID namespace can't see
>>        processes in the parent and further removed ancestor namespace.
>>        More  succinctly:  a  process  can see (e.g., send signals with
>>        kill(2), set nice values with setpriority(2), etc.)  only  pro‐
>>        cesses contained in its own PID namespace and in descendants of
>>        that namespace.
>>
>>        A process has one process ID in each of the layers of  the  PID
>>        namespace  hierarchy  in  which  is  visible,  and walking back
>>        though each direct ancestor namespace through to the  root  PID
>>        namespace.   System  calls  that  operate on process IDs always
>>        operate using the process ID that is visible in the PID  names‐
>>        pace of the caller.  A call to getpid(2) always returns the PID
>>        associated with the namespace in which the process was created.
>>
>>        Some processes in a PID namespace may  have  parents  that  are
>>        outside  of the namespace.  For example, the parent of the ini‐
>>        tial process in the namespace (i.e., the init(1)  process  with
>>        PID  1)  is  necessarily  in  another namespace.  Likewise, the
>>        direct children of a process that uses setns(2)  to  cause  its
>>        children  to join a PID namespace are in a different PID names‐
>>        pace from the caller of setns(2).  Calls to getppid(2) for such
>>        processes return 0.
>>
>>    setns(2) and unshare(2) semantics
>>        Calls  to setns(2) that specify a PID namespace file descriptor
>>        and calls to unshare(2) with the CLONE_NEWPID flag cause  chil‐
>>        dren  subsequently created by the caller to be placed in a dif‐
>>        ferent PID namespace from the caller.  These calls do not, how‐
>>        ever,  change the PID namespace of the calling process, because
>>        doing so would change the caller's idea  of  its  own  PID  (as
>>        reported  by getpid()), which would break many applications and
>>        libraries.
>>
>>        To put things another way: a process's PID namespace membership
>>        is determined when the process is created and cannot be changed
>>        thereafter.  Among other things, this means that  the  parental
>>        relationship between processes mirrors the parental between PID
>>        namespaces: the parent of a  process  is  either  in  the  same
>>        namespace or resides in the immediate parent PID namespace.
>
> This is mostly true.  With setns it is possible to have a parent
> in a pid namespace several steps up the pid namespace hierarchy.
>
>>        Every  thread  in  a process must be in the same PID namespace.
>>        For this reason, the two following call sequences will fail:
>>
>>            unshare(CLONE_NEWPID);
>>            clone(..., CLONE_VM, ...);    /* Fails */
>>
>>            setns(fd, CLONE_NEWPID);
>>            clone(..., CLONE_VM, ...);    /* Fails */
>>
>>        Because the above unshare(2) and setns(2) calls only change the
>>        PID  namespace  for created children, the clone(2) calls neces‐
>>        sarily put the new thread in a different PID namespace from the
>>        calling thread.
>
> I don't know if it is interesting but these sequences also fail.  But I
> suppose that is obvious?  Or documented at least Documented in the clone
> manpage and unshare manpages.
>
>             clone(..., CLONE_VM, ...);
>             unshare(CLONE_NEWPID);       /* Fails */
>
>             clone(..., CLONE_VM, ...);
>             setns(fd, CLONE_NEWPID);     /* Fails */


I added to this page.

>>    Miscellaneous
>>        After  creating a new PID namespace, it is useful for the child
>>        to change its root directory and mount a new procfs instance at
>>        /proc  so  that  tools such as ps(1) work correctly.  (If a new
>>        mount  namespace  is  simultaneously   created   by   including
>>        CLONE_NEWNS  in  the flags argument of clone(2) or unshare(2)),
>>        then it isn't necessary to change the  root  directory:  a  new
>>        procfs instance can be mounted directly over /proc.)
>
> Should it be documented somewhere that /proc when mounted from a pid
> namespace will use the pids of that pid namespace and /proc will only
> show process for visible in the mounting pid namespace, even if that
> mount of proc is accessed by processes in other pid namespaces?
>
> You sort of say it here by saying it is useful to mount a new copy of
> /proc, which it is.  I just don't see you coming out straight and saying
> why it is.  It just seems to be implied.

You're right. I should be more explicit. I will add some text detailing this.

[...]

Thanks for the comments, Eric!

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

Re: For review: pid_namespaces(7) man page

[Eric W. Biederman]

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

> Hi Eric,
>
> On Thu, Feb 28, 2013 at 4:24 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>
> [...]
>
>>> ==========
>>> PID_NAMESPACES(7)      Linux Programmer's Manual     PID_NAMESPACES(7)
>>>
>>> NAME
>>>        pid_namespaces - overview of Linux PID namespaces
>>>
>>> DESCRIPTION
> [...]
>
>>>    The namespace init process
>>>        The first process created in a new namespace (i.e., the process
>>>        created using clone(2) with the CLONE_NEWPID flag, or the first
>>>        child created by a process after a call to unshare(2) using the
>>>        CLONE_NEWPID flag) has the PID 1, and is the "init" process for
>>>        the namespace (see init(1)).  Children that are orphaned within
>>>        the namespace will be reparented to this  process  rather  than
>>>        init(1).
>>>
>>>        If the "init" process of a PID namespace terminates, the kernel
>>>        terminates all of the processes in the namespace via a  SIGKILL
>>>        signal.   This  behavior  reflects  the  fact  that  the "init"
>>>        process is essential for the correct operation of a PID  names‐
>>>        pace.   In this case, a subsequent fork(2) into this PID names‐
>>>        pace (e.g., from a process that has done a  setns(2)  into  the
>>>        namespace    using    an    open    file   descriptor   for   a
>>>        /proc/[pid]/ns/pid file corresponding to a process that was  in
>>>        the  namespace) will fail with the error ENOMEM; it is not pos‐
>>>        sible to create a new processes in a PID namespace whose "init"
>>>        process has terminated.
>>
>> It may be useful to mention unshare in the case of fork(2) failing just
>> because that is such an easy mistake to make.
>>
>> unshare(CLONE_NEWPID);
>> pid = fork();
>> waitpid(pid,...);
>> fork() -> ENOMEM
>
> I'm lost. Why does that sequence fail? The child of fork() becomes PID
> 1 in the new PID namespace.

Correct.
Then we wait for the child of the fork to exit();
Then we fork again into the new pid namespace.
The second fork fails because init has exited.

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

On Fri, Mar 1, 2013 at 10:10 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>
>> Hi Eric,
>>
>> On Thu, Feb 28, 2013 at 4:24 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>
>> [...]
>>
>>>> ==========
>>>> PID_NAMESPACES(7)      Linux Programmer's Manual     PID_NAMESPACES(7)
>>>>
>>>> NAME
>>>>        pid_namespaces - overview of Linux PID namespaces
>>>>
>>>> DESCRIPTION
>> [...]
>>
>>>>    The namespace init process
>>>>        The first process created in a new namespace (i.e., the process
>>>>        created using clone(2) with the CLONE_NEWPID flag, or the first
>>>>        child created by a process after a call to unshare(2) using the
>>>>        CLONE_NEWPID flag) has the PID 1, and is the "init" process for
>>>>        the namespace (see init(1)).  Children that are orphaned within
>>>>        the namespace will be reparented to this  process  rather  than
>>>>        init(1).
>>>>
>>>>        If the "init" process of a PID namespace terminates, the kernel
>>>>        terminates all of the processes in the namespace via a  SIGKILL
>>>>        signal.   This  behavior  reflects  the  fact  that  the "init"
>>>>        process is essential for the correct operation of a PID  names‐
>>>>        pace.   In this case, a subsequent fork(2) into this PID names‐
>>>>        pace (e.g., from a process that has done a  setns(2)  into  the
>>>>        namespace    using    an    open    file   descriptor   for   a
>>>>        /proc/[pid]/ns/pid file corresponding to a process that was  in
>>>>        the  namespace) will fail with the error ENOMEM; it is not pos‐
>>>>        sible to create a new processes in a PID namespace whose "init"
>>>>        process has terminated.
>>>
>>> It may be useful to mention unshare in the case of fork(2) failing just
>>> because that is such an easy mistake to make.
>>>
>>> unshare(CLONE_NEWPID);
>>> pid = fork();
>>> waitpid(pid,...);
>>> fork() -> ENOMEM
>>
>> I'm lost. Why does that sequence fail? The child of fork() becomes PID
>> 1 in the new PID namespace.
>
> Correct.
> Then we wait for the child of the fork to exit();
> Then we fork again into the new pid namespace.
> The second fork fails because init has exited.

Ahhh -- I misapprehended the scenario you were describing. Got it now.
I'll add that case.

Thanks,

Michael
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

[-- Attachment #1: Type: text/plain, Size: 11429 bytes --]

Hello Eric et al.

Here is the current draft of the pid_namespaces(7) man page, which
described PID namespaces. The rendered version is below, and the
source is attached.

Review comments/suggestions for improvements / bug fixes welcome.

Cheers,

Michael

==

NAME
       pid_namespaces - overview of Linux PID namespaces

DESCRIPTION
       For an overview of namespaces, see namespaces(7).

       PID  namespaces isolate the process ID number space, meaning that
       processes in different PID namespaces can have the same PID.  PID
       namespaces allow containers to provide functionality such as sus‐
       pending/resuming the  set  of  processes  in  the  container  and
       migrating  the container to a new host while the processes inside
       the container maintain the same PIDs.

       PIDs in a new PID namespace start at 1, somewhat  like  a  stand‐
       alone  system,  and  calls to fork(2), vfork(2), or clone(2) will
       produce processes with PIDs that are unique within the namespace.

       Use of PID namespaces requires a kernel that is  configured  with
       the CONFIG_PID_NS option.

   The namespace init process
       The  first  process created in a new namespace (i.e., the process
       created using clone(2) with the CLONE_NEWPID flag, or  the  first
       child  created  by a process after a call to unshare(2) using the
       CLONE_NEWPID flag) has the PID 1, and is the "init"  process  for
       the  namespace  (see  init(1)).  A child process that is orphaned
       within the namespace will be reparented to  this  process  rather
       than init(1) (unless one of the ancestors of the child
        in    the    same    PID   namespace   employed   the   prctl(2)
       PR_GET_CHILD_SUBREAPER command to mark itself as  the  reaper  of
       orphaned descendant processes).

       If  the  "init" process of a PID namespace terminates, the kernel
       terminates all of the processes in the namespace  via  a  SIGKILL
       signal.   This behavior reflects the fact that the "init" process
       is essential for the correct operation of a  PID  namespace.   In
       this case, a subsequent fork(2) into this PID namespace will fail
       with the error ENOMEM; it is not possible to create  a  new  pro‐
       cesses  in  a  PID namespace whose "init" process has terminated.
       Such scenarios can occur when, for example,  a  process  uses  an
       open  file descriptor for a /proc/[pid]/ns/pid file corresponding
       to a process that was in a namespace to setns(2) into that names‐
       pace  after  the "init" process has terminated.  Another possible
       scenario can occur after a call to unshare(2): if the first child
       subsequently  created  by  a  fork(2) terminates, then subsequent
       calls to fork(2) will fail with ENOMEM.

       Only signals for which the "init" process has established a  sig‐
       nal handler can be sent to the "init" process by other members of
       the PID namespace.  This restriction applies even  to  privileged
       processes,  and  prevents other members of the PID namespace from
       accidentally killing the "init" process.

       Likewise, a process in an ancestor namespace can—subject  to  the
       usual  permission checks described in kill(2)—send signals to the
       "init" process of a  child  PID  namespace  only  if  the  "init"
       process  has  established a handler for that signal.  (Within the
       handler, the siginfo_t si_pid  field  described  in  sigaction(2)
       will  be  zero.)   SIGKILL  or SIGSTOP are treated exceptionally:
       these signals are forcibly delivered when sent from  an  ancestor
       PID  namespace.   Neither  of  these signals can be caught by the
       "init" process, and so will result in the usual  actions  associ‐
       ated  with  those signals (respectively, terminating and stopping
       the process).

       Starting with Linux 3.4, the reboot(2) system causes a signal  to
       be  sent to the namespace "init" process.  See reboot(2) for more
       details.

   Nesting PID namespaces
       PID namespaces can be nested: each PID namespace  has  a  parent,
       except  for  the initial ("root") PID namespace.  The parent of a
       PID namespace is the PID namespace of the  process  that  created
       the  namespace using clone(2) or unshare(2).  PID namespaces thus
       form a tree, with all namespaces ultimately tracing their  ances‐
       try to the root namespace.

       A process is visible to other processes in its PID namespace, and
       to the processes in each direct ancestor PID namespace going back
       to the root PID namespace.  In this context, "visible" means that
       one process can be the target of operations  by  another  process
       using  system  calls  that specify a process ID.  Conversely, the
       processes in a child PID namespace can't  see  processes  in  the
       parent  and further removed ancestor namespace.  More succinctly:
       a process can see (e.g., send signals with kill(2), set nice val‐
       ues  with  setpriority(2),  etc.) only processes contained in its
       own PID namespace and in descendants of that namespace.

       A process has one process ID in each of the  layers  of  the  PID
       namespace  hierarchy in which is visible, and walking back though
       each direct ancestor namespace through to the root PID namespace.
       System calls that operate on process IDs always operate using the
       process ID that is visible in the PID namespace of the caller.  A
       call  to  getpid(2)  always  returns  the PID associated with the
       namespace in which the process was created.

       Some processes in a PID namespace may have parents that are  out‐
       side  of  the  namespace.  For example, the parent of the initial
       process in the namespace (i.e., the init(1) process with  PID  1)
       is  necessarily in another namespace.  Likewise, the direct chil‐
       dren of a process that uses setns(2) to  cause  its  children  to
       join  a  PID  namespace are in a different PID namespace from the
       caller of setns(2).   Calls  to  getppid(2)  for  such  processes
       return 0.

   setns(2) and unshare(2) semantics
       Calls  to  setns(2)  that specify a PID namespace file descriptor
       and calls to unshare(2) with the CLONE_NEWPID flag cause children
       subsequently  created  by  the caller to be placed in a different
       PID namespace from the caller.   These  calls  do  not,  however,
       change the PID namespace of the calling process, because doing so
       would change the caller's idea of its own  PID  (as  reported  by
       getpid()), which would break many applications and libraries.

       To  put  things another way: a process's PID namespace membership
       is determined when the process is created and cannot  be  changed
       thereafter.   Among  other  things,  this means that the parental
       relationship between processes mirrors the parental  relationship
       between  PID namespaces: the parent of a process is either in the
       same namespace or resides in the immediate parent PID namespace.

   Compatibility of CLONE_NEWPID with other CLONE_* flags
       CLONE_NEWPID can't be combined with some other CLONE_* flags:

       *  CLONE_THREAD requires being in the same PID namespace in order
          that  that  the  threads in a process can send signals to each
          other.  Similarly, it must be  possible  to  see  all  of  the
          threads of a processes in the proc(5) filesystem.

       *  CLONE_SIGHAND requires being in the same PID namespace; other‐
          wise the process ID of the process sending a signal could  not
          be  meaningfully  encoded  when  a  signal  is  sent  (see the
          description of the siginfo_t type in sigaction(2)).  A  signal
          queue  shared  by  processes  in  multiple PID namespaces will
          defeat that.

       *  CLONE_VM requires all of the threads to be  in  the  same  PID
          namespace,  because, from the point of view of a core dump, if
          two processes share the same address space  they  are  threads
          and  will  be core dumped together.  When a core dump is writ‐
          ten, the PID of each thread is written  into  the  core  dump.
          Writing the process IDs could not meaningfully succeed if some
          of the process IDs were in a parent PID namespace.

       To summarize: there  is  a  technical  requirement  for  each  of
       CLONE_THREAD,  CLONE_SIGHAND,  and CLONE_VM to share a PID names‐
       pace.  (Note furthermore that in clone(2) requires CLONE_VM to be
       specified  if CLONE_THREAD or CLONE_SIGHAND is specified.)  Thus,
       call sequences such as the following will fail  (with  the  error
       EINVAL):

           unshare(CLONE_NEWPID);
           clone(..., CLONE_VM, ...);    /* Fails */

           setns(fd, CLONE_NEWPID);
           clone(..., CLONE_VM, ...);    /* Fails */

           clone(..., CLONE_VM, ...);
           setns(fd, CLONE_NEWPID);      /* Fails */

           clone(..., CLONE_VM, ...);
           unshare(CLONE_NEWPID);        /* Fails */

   /proc and PID namespaces
       A /proc filesystem shows (in the /proc/PID directories) only pro‐
       cesses visible in the PID namespace of the process that performed
       the  mount, even if the /proc filesystem is viewed from processes
       in other namespaces.

       After creating a new PID namespace, it is useful for the child to
       change  its  root  directory  and  mount a new procfs instance at
       /proc so that tools such as ps(1) work correctly.  If a new mount
       namespace  is  simultaneously created by including CLONE_NEWNS in
       the flags argument of clone(2) or unshare(2), then it isn't  nec‐
       essary to change the root directory: a new procfs instance can be
       mounted directly over /proc.

       From a shell, the command to mount /proc is:

           $ mount -t proc proc /proc

       Calling readlink(2) on the path /proc/self yields the process  ID
       of the caller in the PID namespace of the procfs mount (i.e., the
       PID namespace of the process that mounted the procfs).  This  can
       be  useful  for  introspection  purposes, when a process wants to
       discover its PID in other namespaces.

   Miscellaneous
       When a process ID is passed  over  a  UNIX  domain  socket  to  a
       process  in  a  different  PID  namespace (see the description of
       SCM_CREDENTIALS in unix(7)), it is  translated  into  the  corre‐
       sponding PID value in the receiving process's PID namespace.

CONFORMING TO
       Namespaces are a Linux-specific feature.

EXAMPLE
       See user_namespaces(7).

SEE ALSO
       clone(2), setns(2), unshare(2), proc(5), credentials(7), capabil‐
       ities(7), user_namespaces(7), switch_root(8)



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

[-- Attachment #2: pid_namespaces.7 --]
[-- Type: application/x-troff-man, Size: 11363 bytes --]

[-- Attachment #3: Type: text/plain, Size: 205 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

[-- Attachment #1: Type: text/plain, Size: 18548 bytes --]

Eric et al,

Eventually, there will be more namespace man pages, but let us start
now with one for PID namespaces. The attached page aims to provide a
fairly complete overview of PID namespaces.

Eric, various pieces of the page are shifted out of other pages
(clone(2), setns(2), etc.) and are derived from comments you've
emailed me off list, so you are (jointly) in the copyright of the
page. I've chosen the common license for man-pages; let me know if you
have any objections to that license.

I'm looking for review comments (corrections, improvements, additions,
etc.) on this page. I've provided it in two forms inline below, and
reviewers can comment comment on whichever form they are most
comfortable with:

1) The rendered page as plain text
2) The *roff source (also attached); rendering that source will enable
readers to see proper formatting for the page.

Note that the namespaces(7) page referred to in this page is not yet
finished; I'll send it out for review at a future time.

Thanks,

Michael

==========
PID_NAMESPACES(7)      Linux Programmer's Manual     PID_NAMESPACES(7)

NAME
       pid_namespaces - overview of Linux PID namespaces

DESCRIPTION
       For an overview of namespaces, see namespaces(7).

       PID  namespaces  isolate  the  process ID number space, meaning
       that processes in different PID namespaces can  have  the  same
       PID.   PID namespaces allow containers to migrate to a new host
       while the processes inside  the  container  maintain  the  same
       PIDs.

       PIDs  in a new PID namespace start at 1, somewhat like a stand‐
       alone system, and calls to fork(2), vfork(2), or clone(2)  will
       produce  processes  with PIDs that are unique within the names‐
       pace.

       Use of PID namespaces requires a kernel that is configured with
       the CONFIG_PID_NS option.

   The namespace init process
       The first process created in a new namespace (i.e., the process
       created using clone(2) with the CLONE_NEWPID flag, or the first
       child created by a process after a call to unshare(2) using the
       CLONE_NEWPID flag) has the PID 1, and is the "init" process for
       the namespace (see init(1)).  Children that are orphaned within
       the namespace will be reparented to this  process  rather  than
       init(1).

       If the "init" process of a PID namespace terminates, the kernel
       terminates all of the processes in the namespace via a  SIGKILL
       signal.   This  behavior  reflects  the  fact  that  the "init"
       process is essential for the correct operation of a PID  names‐
       pace.   In this case, a subsequent fork(2) into this PID names‐
       pace (e.g., from a process that has done a  setns(2)  into  the
       namespace    using    an    open    file   descriptor   for   a
       /proc/[pid]/ns/pid file corresponding to a process that was  in
       the  namespace) will fail with the error ENOMEM; it is not pos‐
       sible to create a new processes in a PID namespace whose "init"
       process has terminated.

       Only  signals  for  which  the "init" process has established a
       signal handler can be sent to the "init" process by other  mem‐
       bers  of  the  PID namespace.  This restriction applies even to
       privileged processes, and prevents other  members  of  the  PID
       namespace from accidentally killing the "init" process.

       Likewise, a process in an ancestor namespace can—subject to the
       usual permission checks described in  kill(2)—send  signals  to
       the  "init" process of a child PID namespace only if the "init"
       process has established a handler for that signal.  (Within the
       handler,  the  siginfo_t si_pid field described in sigaction(2)
       will be zero.)  SIGKILL or SIGSTOP are  treated  exceptionally:
       these signals are forcibly delivered when sent from an ancestor
       PID namespace.  Neither of these signals can be caught  by  the
       "init" process, and so will result in the usual actions associ‐
       ated with those signals (respectively, terminating and stopping
       the process).

   Nesting PID namespaces
       PID  namespaces can be nested: each PID namespace has a parent,
       except for the initial ("root") PID namespace.  The parent of a
       PID  namespace is the PID namespace of the process that created
       the namespace using clone(2)  or  unshare(2).   PID  namespaces
       thus  form a tree, with all namespaces ultimately tracing their
       ancestry to the root namespace.

       A process is visible to other processes in its  PID  namespace,
       and  to  the  processes  in  each direct ancestor PID namespace
       going back to the root PID namespace.  In this context,  "visi‐
       ble"  means that one process can be the target of operations by
       another process using system calls that specify a  process  ID.
       Conversely,  the  processes  in a child PID namespace can't see
       processes in the parent and further removed ancestor namespace.
       More  succinctly:  a  process  can see (e.g., send signals with
       kill(2), set nice values with setpriority(2), etc.)  only  pro‐
       cesses contained in its own PID namespace and in descendants of
       that namespace.

       A process has one process ID in each of the layers of  the  PID
       namespace  hierarchy  in  which  is  visible,  and walking back
       though each direct ancestor namespace through to the  root  PID
       namespace.   System  calls  that  operate on process IDs always
       operate using the process ID that is visible in the PID  names‐
       pace of the caller.  A call to getpid(2) always returns the PID
       associated with the namespace in which the process was created.

       Some processes in a PID namespace may  have  parents  that  are
       outside  of the namespace.  For example, the parent of the ini‐
       tial process in the namespace (i.e., the init(1)  process  with
       PID  1)  is  necessarily  in  another namespace.  Likewise, the
       direct children of a process that uses setns(2)  to  cause  its
       children  to join a PID namespace are in a different PID names‐
       pace from the caller of setns(2).  Calls to getppid(2) for such
       processes return 0.

   setns(2) and unshare(2) semantics
       Calls  to setns(2) that specify a PID namespace file descriptor
       and calls to unshare(2) with the CLONE_NEWPID flag cause  chil‐
       dren  subsequently created by the caller to be placed in a dif‐
       ferent PID namespace from the caller.  These calls do not, how‐
       ever,  change the PID namespace of the calling process, because
       doing so would change the caller's idea  of  its  own  PID  (as
       reported  by getpid()), which would break many applications and
       libraries.

       To put things another way: a process's PID namespace membership
       is determined when the process is created and cannot be changed
       thereafter.  Among other things, this means that  the  parental
       relationship between processes mirrors the parental between PID
       namespaces: the parent of a  process  is  either  in  the  same
       namespace or resides in the immediate parent PID namespace.

       Every  thread  in  a process must be in the same PID namespace.
       For this reason, the two following call sequences will fail:

           unshare(CLONE_NEWPID);
           clone(..., CLONE_VM, ...);    /* Fails */

           setns(fd, CLONE_NEWPID);
           clone(..., CLONE_VM, ...);    /* Fails */

       Because the above unshare(2) and setns(2) calls only change the
       PID  namespace  for created children, the clone(2) calls neces‐
       sarily put the new thread in a different PID namespace from the
       calling thread.

   Miscellaneous
       After  creating a new PID namespace, it is useful for the child
       to change its root directory and mount a new procfs instance at
       /proc  so  that  tools such as ps(1) work correctly.  (If a new
       mount  namespace  is  simultaneously   created   by   including
       CLONE_NEWNS  in  the flags argument of clone(2) or unshare(2)),
       then it isn't necessary to change the  root  directory:  a  new
       procfs instance can be mounted directly over /proc.)

       Calling  readlink(2)  on the path /proc/self yields the process
       ID of the caller in the  PID  namespace  of  the  procfs  mount
       (i.e.,  the  PID  namespace  of  the  process  that mounted the
       procfs).

       When a process ID is passed over a  UNIX  domain  socket  to  a
       process  in  a  different PID namespace (see the description of
       SCM_CREDENTIALS in unix(7)), it is translated into  the  corre‐
       sponding PID value in the receiving process's PID namespace.

CONFORMING TO
       Namespaces are a Linux-specific feature.

SEE ALSO
       unshare(1),  clone(2),  setns(2),  unshare(2), proc(5), creden‐
       tials(7), capabilities(7), user_namespaces(7), switch_root(8)



Linux                         2013-01-14             PID_NAMESPACES(7)


=========== *roff source ==========

$ cat pid_namespaces.7
.\" Copyright (c) 2013 by Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
.\" and Copyright (c) 2012 by Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\"
.\"
.TH PID_NAMESPACES 7 2013-01-14 "Linux" "Linux Programmer's Manual"
.SH NAME
pid_namespaces \- overview of Linux PID namespaces
.SH DESCRIPTION
For an overview of namespaces, see
.BR namespaces (7).

PID namespaces isolate the process ID number space,
meaning that processes in different PID namespaces can have the same PID.
PID namespaces allow containers to migrate to a new host
while the processes inside the container maintain the same PIDs.

PIDs in a new PID namespace start at 1,
somewhat like a standalone system, and calls to
.BR fork (2),
.BR vfork (2),
or
.BR clone (2)
will produce processes with PIDs that are unique within the namespace.

Use of PID namespaces requires a kernel that is configured with the
.B CONFIG_PID_NS
option.
.\"
.\" ============================================================
.\"
.SS The namespace "init" process
The first process created in a new namespace
(i.e., the process created using
.BR clone (2)
with the
.BR CLONE_NEWPID
flag, or the first child created by a process after a call to
.BR unshare (2)
using the
.BR CLONE_NEWPID
flag) has the PID 1, and is the "init" process for the namespace (see
.BR init (1)).
Children that are orphaned within the namespace will be reparented
to this process rather than
.BR init (1).

If the "init" process of a PID namespace terminates,
the kernel terminates all of the processes in the namespace via a
.BR SIGKILL
signal.
This behavior reflects the fact that the "init" process
is essential for the correct operation of a PID namespace.
In this case, a subsequent
.BR fork (2)
into this PID namespace (e.g., from a process that has done a
.BR setns (2)
into the namespace using an open file descriptor for a
.I /proc/[pid]/ns/pid
file corresponding to a process that was in the namespace)
will fail with the error
.BR ENOMEM ;
it is not possible to create a new processes in a PID namespace whose "init"
process has terminated.

Only signals for which the "init" process has established a signal handler
can be sent to the "init" process by other members of the PID namespace.
This restriction applies even to privileged processes,
and prevents other members of the PID namespace from
accidentally killing the "init" process.

Likewise, a process in an ancestor namespace
can\(emsubject to the usual permission checks described in
.BR kill (2)\(emsend
signals to the "init" process of a child PID namespace only
if the "init" process has established a handler for that signal.
(Within the handler, the
.I siginfo_t
.I si_pid
field described in
.BR sigaction (2)
will be zero.)
.B SIGKILL
or
.B SIGSTOP
are treated exceptionally:
these signals are forcibly delivered when sent from an ancestor PID namespace.
Neither of these signals can be caught by the "init" process,
and so will result in the usual actions associated with those signals
(respectively, terminating and stopping the process).
.\"
.\" ============================================================
.\"
.SS Nesting PID namespaces
PID namespaces can be nested:
each PID namespace has a parent,
except for the initial ("root") PID namespace.
The parent of a PID namespace is the PID namespace of the process that
created the namespace using
.BR clone (2)
or
.BR unshare (2).
PID namespaces thus form a tree,
with all namespaces ultimately tracing their ancestry to the root namespace.

A process is visible to other processes in its PID namespace,
and to the processes in each direct ancestor PID namespace
going back to the root PID namespace.
In this context, "visible" means that one process
can be the target of operations by another process using
system calls that specify a process ID.
Conversely, the processes in a child PID namespace can't see
processes in the parent and further removed ancestor namespace.
More succinctly: a process can see (e.g., send signals with
.BR kill(2),
set nice values with
.BR setpriority (2),
etc.) only processes contained in its own PID namespace
and in descendants of that namespace.

A process has one process ID in each of the layers of the PID
namespace hierarchy in which is visible,
and walking back though each direct ancestor namespace
through to the root PID namespace.
System calls that operate on process IDs always
operate using the process ID that is visible in the
PID namespace of the caller.
A call to
.BR getpid (2)
always returns the PID associated with the namespace in which
the process was created.

Some processes in a PID namespace may have parents
that are outside of the namespace.
For example, the parent of the initial process in the namespace
(i.e., the
.BR init (1)
process with PID 1) is necessarily in another namespace.
Likewise, the direct children of a process that uses
.BR setns (2)
to cause its children to join a PID namespace are in a different
PID namespace from the caller of
.BR setns (2).
Calls to
.BR getppid (2)
for such processes return 0.
.\"
.\" ============================================================
.\"
.SS setns(2) and unshare(2) semantics
Calls to
.BR setns (2)
that specify a PID namespace file descriptor
and calls to
.BR unshare (2)
with the
.BR CLONE_NEWPID
flag cause children subsequently created
by the caller to be placed in a different PID namespace from the caller.
These calls do not, however,
change the PID namespace of the calling process,
because doing so would change the caller's idea of its own PID
(as reported by
.BR getpid ()),
which would break many applications and libraries.

To put things another way:
a process's PID namespace membership is determined when the process is created
and cannot be changed thereafter.
Among other things, this means that the parental relationship
between processes mirrors the parental between PID namespaces:
the parent of a process is either in the same namespace
or resides in the immediate parent PID namespace.

Every thread in a process must be in the same PID namespace.
For this reason, the two following call sequences will fail:

.nf
    unshare(CLONE_NEWPID);
    clone(..., CLONE_VM, ...);    /* Fails */

    setns(fd, CLONE_NEWPID);
    clone(..., CLONE_VM, ...);    /* Fails */
.fi

Because the above
.BR unshare (2)
and
.BR setns (2)
calls only change the PID namespace for created children, the
.BR clone (2)
calls necessarily put the new thread in a different PID namespace from
the calling thread.
.\"
.\" ============================================================
.\"
.SS Miscellaneous
After creating a new PID namespace,
it is useful for the child to change its root directory
and mount a new procfs instance at
.I /proc
so that tools such as
.BR ps (1)
work correctly.
.\" mount -t proc proc /proc
(If a new mount namespace is simultaneously created by including
.BR CLONE_NEWNS
in the
.IR flags
argument of
.BR clone (2)
or
.BR unshare (2)),
then it isn't necessary to change the root directory:
a new procfs instance can be mounted directly over
.IR /proc .)

Calling
.BR readlink (2)
on the path
.I /proc/self
yields the process ID of the caller in the PID namespace of the procfs mount
(i.e., the PID namespace of the process that mounted the procfs).

When a process ID is passed over a UNIX domain socket to a
process in a different PID namespace (see the description of
.B SCM_CREDENTIALS
in
.BR unix (7)),
it is translated into the corresponding PID value in
the receiving process's PID namespace.
.SH CONFORMING TO
Namespaces are a Linux-specific feature.
.SH SEE ALSO
.BR unshare (1),
.BR clone (2),
.BR setns (2),
.BR unshare (2),
.BR proc (5),
.BR credentials (7),
.BR capabilities (7),
.BR user_namespaces (7),
.BR switch_root (8)

[-- Attachment #2: pid_namespaces.7 --]
[-- Type: application/octet-stream, Size: 8766 bytes --]

.\" Copyright (c) 2013 by Michael Kerrisk <mtk.manpages@gmail.com>
.\" and Copyright (c) 2012 by Eric W. Biederman <ebiederm@xmission.com>
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\"
.\"
.TH PID_NAMESPACES 7 2013-01-14 "Linux" "Linux Programmer's Manual"
.SH NAME
pid_namespaces \- overview of Linux PID namespaces
.SH DESCRIPTION
For an overview of namespaces, see
.BR namespaces (7).

PID namespaces isolate the process ID number space,
meaning that processes in different PID namespaces can have the same PID.
PID namespaces allow containers to migrate to a new host
while the processes inside the container maintain the same PIDs.

PIDs in a new PID namespace start at 1,
somewhat like a standalone system, and calls to
.BR fork (2),
.BR vfork (2),
or
.BR clone (2)
will produce processes with PIDs that are unique within the namespace.

Use of PID namespaces requires a kernel that is configured with the
.B CONFIG_PID_NS
option.
.\"
.\" ============================================================
.\"
.SS The namespace "init" process
The first process created in a new namespace
(i.e., the process created using
.BR clone (2)
with the
.BR CLONE_NEWPID
flag, or the first child created by a process after a call to
.BR unshare (2)
using the
.BR CLONE_NEWPID
flag) has the PID 1, and is the "init" process for the namespace (see
.BR init (1)).
Children that are orphaned within the namespace will be reparented
to this process rather than
.BR init (1).

If the "init" process of a PID namespace terminates,
the kernel terminates all of the processes in the namespace via a
.BR SIGKILL
signal.
This behavior reflects the fact that the "init" process
is essential for the correct operation of a PID namespace.
In this case, a subsequent
.BR fork (2)
into this PID namespace (e.g., from a process that has done a
.BR setns (2)
into the namespace using an open file descriptor for a
.I /proc/[pid]/ns/pid
file corresponding to a process that was in the namespace)
will fail with the error
.BR ENOMEM ;
it is not possible to create a new processes in a PID namespace whose "init"
process has terminated.

Only signals for which the "init" process has established a signal handler
can be sent to the "init" process by other members of the PID namespace.
This restriction applies even to privileged processes,
and prevents other members of the PID namespace from
accidentally killing the "init" process.

Likewise, a process in an ancestor namespace
can\(emsubject to the usual permission checks described in
.BR kill (2)\(emsend
signals to the "init" process of a child PID namespace only
if the "init" process has established a handler for that signal.
(Within the handler, the
.I siginfo_t
.I si_pid
field described in
.BR sigaction (2)
will be zero.)
.B SIGKILL
or
.B SIGSTOP
are treated exceptionally:
these signals are forcibly delivered when sent from an ancestor PID namespace.
Neither of these signals can be caught by the "init" process,
and so will result in the usual actions associated with those signals
(respectively, terminating and stopping the process).
.\"
.\" ============================================================
.\"
.SS Nesting PID namespaces
PID namespaces can be nested:
each PID namespace has a parent,
except for the initial ("root") PID namespace.
The parent of a PID namespace is the PID namespace of the process that
created the namespace using
.BR clone (2)
or
.BR unshare (2).
PID namespaces thus form a tree,
with all namespaces ultimately tracing their ancestry to the root namespace.

A process is visible to other processes in its PID namespace,
and to the processes in each direct ancestor PID namespace
going back to the root PID namespace.
In this context, "visible" means that one process
can be the target of operations by another process using
system calls that specify a process ID.
Conversely, the processes in a child PID namespace can't see
processes in the parent and further removed ancestor namespace.
More succinctly: a process can see (e.g., send signals with
.BR kill(2),
set nice values with
.BR setpriority (2),
etc.) only processes contained in its own PID namespace
and in descendants of that namespace.

A process has one process ID in each of the layers of the PID
namespace hierarchy in which is visible,
and walking back though each direct ancestor namespace
through to the root PID namespace.
System calls that operate on process IDs always
operate using the process ID that is visible in the
PID namespace of the caller.
A call to
.BR getpid (2)
always returns the PID associated with the namespace in which
the process was created.

Some processes in a PID namespace may have parents
that are outside of the namespace.
For example, the parent of the initial process in the namespace
(i.e., the
.BR init (1)
process with PID 1) is necessarily in another namespace.
Likewise, the direct children of a process that uses
.BR setns (2)
to cause its children to join a PID namespace are in a different
PID namespace from the caller of
.BR setns (2).
Calls to
.BR getppid (2)
for such processes return 0.
.\"
.\" ============================================================
.\"
.SS setns(2) and unshare(2) semantics
Calls to
.BR setns (2)
that specify a PID namespace file descriptor
and calls to
.BR unshare (2)
with the
.BR CLONE_NEWPID
flag cause children subsequently created
by the caller to be placed in a different PID namespace from the caller.
These calls do not, however,
change the PID namespace of the calling process,
because doing so would change the caller's idea of its own PID
(as reported by
.BR getpid ()),
which would break many applications and libraries.

To put things another way:
a process's PID namespace membership is determined when the process is created
and cannot be changed thereafter.
Among other things, this means that the parental relationship
between processes mirrors the parental between PID namespaces:
the parent of a process is either in the same namespace
or resides in the immediate parent PID namespace.

Every thread in a process must be in the same PID namespace.
For this reason, the two following call sequences will fail:

.nf
    unshare(CLONE_NEWPID);
    clone(..., CLONE_VM, ...);    /* Fails */

    setns(fd, CLONE_NEWPID);
    clone(..., CLONE_VM, ...);    /* Fails */
.fi

Because the above
.BR unshare (2)
and
.BR setns (2)
calls only change the PID namespace for created children, the
.BR clone (2)
calls necessarily put the new thread in a different PID namespace from
the calling thread.
.\"
.\" ============================================================
.\"
.SS Miscellaneous
After creating a new PID namespace,
it is useful for the child to change its root directory
and mount a new procfs instance at
.I /proc
so that tools such as
.BR ps (1)
work correctly.
.\" mount -t proc proc /proc
(If a new mount namespace is simultaneously created by including
.BR CLONE_NEWNS
in the
.IR flags
argument of
.BR clone (2)
or
.BR unshare (2)),
then it isn't necessary to change the root directory:
a new procfs instance can be mounted directly over
.IR /proc .)

Calling
.BR readlink (2)
on the path
.I /proc/self
yields the process ID of the caller in the PID namespace of the procfs mount
(i.e., the PID namespace of the process that mounted the procfs).

When a process ID is passed over a UNIX domain socket to a
process in a different PID namespace (see the description of
.B SCM_CREDENTIALS
in
.BR unix (7)),
it is translated into the corresponding PID value in
the receiving process's PID namespace.
.SH CONFORMING TO
Namespaces are a Linux-specific feature.
.SH SEE ALSO
.BR unshare (1),
.BR clone (2),
.BR setns (2),
.BR unshare (2),
.BR proc (5),
.BR credentials (7),
.BR capabilities (7),
.BR user_namespaces (7),
.BR switch_root (8)

[-- Attachment #3: Type: text/plain, Size: 205 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers