* For review: pid_namespaces(7) man page
@ 2013-02-28 11:24 Michael Kerrisk (man-pages)
[not found] ` <CAKgNAki=mUYuu_Ewhe7sjCmo+Dq2Vr+FZCixqNRaadcvAxtpFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-02-28 11:24 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linux Containers, Serge E. Hallyn, lkml, linux-man
[-- 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)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <CAKgNAki=mUYuu_Ewhe7sjCmo+Dq2Vr+FZCixqNRaadcvAxtpFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2013-02-28 14:24 ` Vasily Kulikov
2013-03-01 8:03 ` Michael Kerrisk (man-pages)
2013-02-28 15:24 ` Eric W. Biederman
2013-03-01 4:01 ` Rob Landley
2 siblings, 1 reply; 31+ messages in thread
From: Vasily Kulikov @ 2013-02-28 14:24 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Eric W. Biederman, linux-man, Linux Containers, lkml
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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <CAKgNAki=mUYuu_Ewhe7sjCmo+Dq2Vr+FZCixqNRaadcvAxtpFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-28 14:24 ` Vasily Kulikov
@ 2013-02-28 15:24 ` Eric W. Biederman
[not found] ` <87txowa2cm.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-01 4:01 ` Rob Landley
2 siblings, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2013-02-28 15:24 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: Linux Containers, Serge E. Hallyn, lkml, linux-man
"Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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)
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <CAKgNAki=mUYuu_Ewhe7sjCmo+Dq2Vr+FZCixqNRaadcvAxtpFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-28 14:24 ` Vasily Kulikov
2013-02-28 15:24 ` Eric W. Biederman
@ 2013-03-01 4:01 ` Rob Landley
2013-03-01 6:58 ` Eric W. Biederman
2013-03-01 9:57 ` Michael Kerrisk (man-pages)
2 siblings, 2 replies; 31+ messages in thread
From: Rob Landley @ 2013-03-01 4:01 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-man, Linux Containers, Eric W. Biederman, lkml
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
2013-03-01 4:01 ` Rob Landley
@ 2013-03-01 6:58 ` Eric W. Biederman
2013-03-01 9:57 ` Michael Kerrisk (man-pages)
1 sibling, 0 replies; 31+ messages in thread
From: Eric W. Biederman @ 2013-03-01 6:58 UTC (permalink / raw)
To: Rob Landley
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, linux-man, Linux Containers,
lkml
Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
2013-02-28 14:24 ` Vasily Kulikov
@ 2013-03-01 8:03 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjXAfq4RwtX1ELier+GLv0D5e9spM3Os3-oqSCXGqRqOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-01 8:03 UTC (permalink / raw)
To: Vasily Kulikov
Cc: linux-man, Linux Containers, Eric W. Biederman,
Lennart Poettering, lkml
[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/
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <CAKgNAkjXAfq4RwtX1ELier+GLv0D5e9spM3Os3-oqSCXGqRqOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2013-03-01 8:36 ` Eric W. Biederman
[not found] ` <87fw0f5xfw.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
0 siblings, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2013-03-01 8:36 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: Vasily Kulikov, linux-man, Linux Containers, lkml,
Lennart Poettering
"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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <87txowa2cm.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2013-03-01 8:50 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjxrbcpONCU4UdD0-cjXwbHr+YwkOR0H_aXp3CGB283Uw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-01 8:50 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linux Containers, Serge E. Hallyn, lkml, linux-man
Hi Eric,
On Thu, Feb 28, 2013 at 4:24 PM, Eric W. Biederman
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <87fw0f5xfw.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2013-03-01 8:53 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-01 8:53 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-man, Linux Containers, Vasily Kulikov, Lennart Poettering,
lkml
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/
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <CAKgNAkjxrbcpONCU4UdD0-cjXwbHr+YwkOR0H_aXp3CGB283Uw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2013-03-01 9:10 ` Eric W. Biederman
[not found] ` <877glr5vuo.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
0 siblings, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2013-03-01 9:10 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man, Linux Containers, lkml
"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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
2013-03-01 4:01 ` Rob Landley
2013-03-01 6:58 ` Eric W. Biederman
@ 2013-03-01 9:57 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkgVKnhRT1Lpq4a_UdBKB+tn6XmWSDF2QJXG0aSLtNH6dg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
1 sibling, 1 reply; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-01 9:57 UTC (permalink / raw)
To: Rob Landley; +Cc: linux-man, Linux Containers, Eric W. Biederman, lkml
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <877glr5vuo.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2013-03-01 10:20 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-01 10:20 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linux Containers, Serge E. Hallyn, lkml, linux-man
On Fri, Mar 1, 2013 at 10:10 AM, Eric W. Biederman
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> Hi Eric,
>>
>> On Thu, Feb 28, 2013 at 4:24 PM, Eric W. Biederman
>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <CAKgNAkgVKnhRT1Lpq4a_UdBKB+tn6XmWSDF2QJXG0aSLtNH6dg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2013-03-01 15:35 ` Eric W. Biederman
[not found] ` <87wqtr3zg5.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-04 3:50 ` Rob Landley
1 sibling, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2013-03-01 15:35 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: Rob Landley, linux-man, Linux Containers, lkml
"Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> Hi Rob,
>
> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <CAKgNAkgVKnhRT1Lpq4a_UdBKB+tn6XmWSDF2QJXG0aSLtNH6dg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-01 15:35 ` Eric W. Biederman
@ 2013-03-04 3:50 ` Rob Landley
2013-03-04 4:03 ` Eric W. Biederman
2013-03-04 12:50 ` Michael Kerrisk (man-pages)
1 sibling, 2 replies; 31+ messages in thread
From: Rob Landley @ 2013-03-04 3:50 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-man, Linux Containers, Eric W. Biederman, lkml
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
2013-03-04 3:50 ` Rob Landley
@ 2013-03-04 4:03 ` Eric W. Biederman
[not found] ` <876217olp0.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-04 12:50 ` Michael Kerrisk (man-pages)
1 sibling, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2013-03-04 4:03 UTC (permalink / raw)
To: Rob Landley
Cc: linux-man, Linux Containers, mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
lkml
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <87wqtr3zg5.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2013-03-04 12:46 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjGD0FdQqpA+rYR=+Yc5uVPB8mE5JjCqy-5WS85cPsvng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-04 12:46 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Rob Landley, linux-man, Linux Containers, lkml
On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman <ebiederm-aS9lmoZGLiXQFizaE/u3fw@public.gmane.orgm> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> Hi Rob,
>>
>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <876217olp0.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2013-03-04 12:48 ` Michael Kerrisk (man-pages)
2013-03-04 19:27 ` Rob Landley
1 sibling, 0 replies; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-04 12:48 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Rob Landley, linux-man, Linux Containers, lkml
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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
2013-03-04 3:50 ` Rob Landley
2013-03-04 4:03 ` Eric W. Biederman
@ 2013-03-04 12:50 ` Michael Kerrisk (man-pages)
1 sibling, 0 replies; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-04 12:50 UTC (permalink / raw)
To: Rob Landley; +Cc: Eric W. Biederman, linux-man, Linux Containers, lkml
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/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <CAKgNAkjGD0FdQqpA+rYR=+Yc5uVPB8mE5JjCqy-5WS85cPsvng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2013-03-04 17:52 ` Eric W. Biederman
[not found] ` <87k3pnhx2k.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
0 siblings, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2013-03-04 17:52 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man, Linux Containers, lkml
"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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <876217olp0.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-04 12:48 ` Michael Kerrisk (man-pages)
@ 2013-03-04 19:27 ` Rob Landley
2013-03-05 7:01 ` Michael Kerrisk (man-pages)
1 sibling, 1 reply; 31+ messages in thread
From: Rob Landley @ 2013-03-04 19:27 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-man, Linux Containers, mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
lkml
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <87k3pnhx2k.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2013-03-05 5:30 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjYmvjMzC+nYqsjHf4bQn2ZwdE5wawoP2p32ZSo+0dfcQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-06 1:58 ` Rob Landley
1 sibling, 1 reply; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-05 5:30 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-man, Linux Containers, lkml
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <CAKgNAkjYmvjMzC+nYqsjHf4bQn2ZwdE5wawoP2p32ZSo+0dfcQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2013-03-05 6:23 ` Michael Kerrisk (man-pages)
2013-03-05 6:41 ` Eric W. Biederman
1 sibling, 0 replies; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-05 6:23 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Rob Landley, linux-man, Linux Containers, lkml
[Resending, since my mobile device turned things into HTML]
Eric,
On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman <ebiederm-aS9lmoZGLiXQFizaE/u3fw@public.gmane.orgm> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>
>>>> Hi Rob,
>>>>
>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <CAKgNAkjYmvjMzC+nYqsjHf4bQn2ZwdE5wawoP2p32ZSo+0dfcQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-05 6:23 ` Michael Kerrisk (man-pages)
@ 2013-03-05 6:41 ` Eric W. Biederman
[not found] ` <87r4jucprp.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
1 sibling, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2013-03-05 6:41 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: Rob Landley, linux-man, Linux Containers, lkml
"Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> Eric,
>
> On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman
> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman
> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>
>>>>> Hi Rob,
>>>>>
>>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
2013-03-04 19:27 ` Rob Landley
@ 2013-03-05 7:01 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-05 7:01 UTC (permalink / raw)
To: Rob Landley; +Cc: Eric W. Biederman, linux-man, Linux Containers, lkml
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/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <87r4jucprp.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2013-03-05 8:37 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkgqE7owqsmD+9-9fZtzMQ76H53a+Aat0CH670jNTUfbFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-05 8:37 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Rob Landley, linux-man, Linux Containers, lkml
On Tue, Mar 5, 2013 at 7:41 AM, Eric W. Biederman <ebiederm-aS9lmoZGLiXQFizaE/u3fw@public.gmane.orgm> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> Eric,
>>
>> On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman
>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>
>>>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman
>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>>>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>
>>>>>> Hi Rob,
>>>>>>
>>>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
>> 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <CAKgNAkgqE7owqsmD+9-9fZtzMQ76H53a+Aat0CH670jNTUfbFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2013-03-06 0:40 ` Eric W. Biederman
[not found] ` <87boax4axy.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
0 siblings, 1 reply; 31+ messages in thread
From: Eric W. Biederman @ 2013-03-06 0:40 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: Rob Landley, linux-man, Linux Containers, lkml
"Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On Tue, Mar 5, 2013 at 7:41 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>>> Eric,
>>>
>>> On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman
>>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>
>>>>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman
>>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>>>>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>>
>>>>>>> Hi Rob,
>>>>>>>
>>>>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
>>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <87k3pnhx2k.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-05 5:30 ` Michael Kerrisk (man-pages)
@ 2013-03-06 1:58 ` Rob Landley
2013-03-06 2:23 ` Eric W. Biederman
1 sibling, 1 reply; 31+ messages in thread
From: Rob Landley @ 2013-03-06 1:58 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-man, Linux Containers, mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
lkml
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
2013-03-06 1:58 ` Rob Landley
@ 2013-03-06 2:23 ` Eric W. Biederman
0 siblings, 0 replies; 31+ messages in thread
From: Eric W. Biederman @ 2013-03-06 2:23 UTC (permalink / raw)
To: Rob Landley
Cc: linux-man, Linux Containers, mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
lkml
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <87boax4axy.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
@ 2013-03-07 8:20 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkgRs7kg5PsMrBDNO8_z=5L5zM7DmLgU8pNwT_ck4Hmvhw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2013-03-07 8:20 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-man, Linux Containers, lkml
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: For review: pid_namespaces(7) man page
[not found] ` <CAKgNAkgRs7kg5PsMrBDNO8_z=5L5zM7DmLgU8pNwT_ck4Hmvhw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2013-03-07 8:31 ` Eric W. Biederman
0 siblings, 0 replies; 31+ messages in thread
From: Eric W. Biederman @ 2013-03-07 8:31 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: Rob Landley, linux-man, Linux Containers, lkml
"Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On Wed, Mar 6, 2013 at 1:40 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>>> On Tue, Mar 5, 2013 at 7:41 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>>>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>
>>>>> Eric,
>>>>>
>>>>> On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman
>>>>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>>>>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>>
>>>>>>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman
>>>>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>>>>>>> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>>>>
>>>>>>>>> Hi Rob,
>>>>>>>>>
>>>>>>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
>>>>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* For review: pid_namespaces(7) man page
@ 2014-08-20 23:38 Michael Kerrisk (man-pages)
0 siblings, 0 replies; 31+ messages in thread
From: Michael Kerrisk (man-pages) @ 2014-08-20 23:38 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
richard.weinberger-Re5JQEeQqe8AvxtiuMwx3w,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, lkml,
Andy Lutomirski, mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
[-- 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: 11364 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
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2014-08-20 23:38 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-28 11:24 For review: pid_namespaces(7) man page Michael Kerrisk (man-pages)
[not found] ` <CAKgNAki=mUYuu_Ewhe7sjCmo+Dq2Vr+FZCixqNRaadcvAxtpFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-28 14:24 ` Vasily Kulikov
2013-03-01 8:03 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjXAfq4RwtX1ELier+GLv0D5e9spM3Os3-oqSCXGqRqOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-01 8:36 ` Eric W. Biederman
[not found] ` <87fw0f5xfw.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-01 8:53 ` Michael Kerrisk (man-pages)
2013-02-28 15:24 ` Eric W. Biederman
[not found] ` <87txowa2cm.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-01 8:50 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjxrbcpONCU4UdD0-cjXwbHr+YwkOR0H_aXp3CGB283Uw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-01 9:10 ` Eric W. Biederman
[not found] ` <877glr5vuo.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-01 10:20 ` Michael Kerrisk (man-pages)
2013-03-01 4:01 ` Rob Landley
2013-03-01 6:58 ` Eric W. Biederman
2013-03-01 9:57 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkgVKnhRT1Lpq4a_UdBKB+tn6XmWSDF2QJXG0aSLtNH6dg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-01 15:35 ` Eric W. Biederman
[not found] ` <87wqtr3zg5.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-04 12:46 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjGD0FdQqpA+rYR=+Yc5uVPB8mE5JjCqy-5WS85cPsvng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-04 17:52 ` Eric W. Biederman
[not found] ` <87k3pnhx2k.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-05 5:30 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjYmvjMzC+nYqsjHf4bQn2ZwdE5wawoP2p32ZSo+0dfcQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-05 6:23 ` Michael Kerrisk (man-pages)
2013-03-05 6:41 ` Eric W. Biederman
[not found] ` <87r4jucprp.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-05 8:37 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkgqE7owqsmD+9-9fZtzMQ76H53a+Aat0CH670jNTUfbFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-06 0:40 ` Eric W. Biederman
[not found] ` <87boax4axy.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-07 8:20 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkgRs7kg5PsMrBDNO8_z=5L5zM7DmLgU8pNwT_ck4Hmvhw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-07 8:31 ` Eric W. Biederman
2013-03-06 1:58 ` Rob Landley
2013-03-06 2:23 ` Eric W. Biederman
2013-03-04 3:50 ` Rob Landley
2013-03-04 4:03 ` Eric W. Biederman
[not found] ` <876217olp0.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-04 12:48 ` Michael Kerrisk (man-pages)
2013-03-04 19:27 ` Rob Landley
2013-03-05 7:01 ` Michael Kerrisk (man-pages)
2013-03-04 12:50 ` Michael Kerrisk (man-pages)
-- strict thread matches above, loose matches on Subject: below --
2014-08-20 23:38 Michael Kerrisk (man-pages)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).