+.\" Copyright (c) 2013 by Michael Kerrisk <mtk.manpages@gmail.com>
+.\" and Copyright (c) 2012 by Eric W. Biederman <ebiederm@xmission.com>
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" 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.
+.\" %%%LICENSE_END
+.\"
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH PID_NAMESPACES 7 2014\-09\-21 Linux "Linux Programmer's Manual"
+.SH 名前
+pid_namespaces \- Linux PID 名前空間の概要
+.SH 説明
+名前空間の概要については \fBnamespaces\fP(7) を参照。
+
+PID 名前空間はプロセス ID 番号空間を分離する。 これは、異なる PID 名前空間のプロセスは同じ PID を持つことができることを意味する。
+PID 名前空間を使うことで、コンテナー内のプロセス群を中断、再開したり、 コンテナー内のプロセスの PID
+を保持したままコンテナーを新しいホストに移行したりするといった機能をコンテナーが提供することが可能になる。
+
+新しい PID 名前空間の PID は、 独立したシステムであるかのように、 1 から始まる。 \fBfork\fP(2), \fBvfork\fP(2),
+\fBclone\fP(2) を呼び出すと、 その名前空間内で一意な PID でプロセスが生成される。
+
+.\"
+.\" ============================================================
+.\"
+PID 名前空間を使用するには、設定 \fBCONFIG_PID_NS\fP が有効になったカーネルが必要である。
+.SS "名前空間の init プロセス"
+新しい名前空間で作成される最初のプロセス (すなわち、\fBCLONE_NEWPID\fP フラグで \fBclone\fP(2) を使って作成されたプロセスや、
+\fBCLONE_NEWPID\fP フラグで \fBunshare\fP(2) を呼び出した後のプロセスによって作成された最初のプロセス) は PID 1
+を持ち、 そのプロセスはその名前空間の "init" プロセスとなる (\fBinit\fP(1) 参照)。 名前空間内でみなしごになった
+(親プロセスがいなくなった) 子プロセスは、 \fBinit\fP(1) ではなくこのプロセスが親プロセスになる (ただし、 同じ PID
+名前空間内のその子プロセスの先祖が、 \fBprctl\fP(2) の \fBPR_SET_CHILD_SUBREAPER\fP コマンドを使って、
+自分自身をみなしごとなった子孫のプロセスの引き取り手になっている場合はこの限りではなく)。
+
+PID 名前空間の "init" プロセスが終了すると、 カーネルはその名前空間の全プロセスを \fBSIGKILL\fP シグナルで終了する。 この動作は、
+PID 名前空間の正しい操作のためには "init" プロセスは不可欠であるという事実を反映したものである。 この場合、 その PID
+名前空間へのそれ以降の \fBfork\fP(2) はエラー \fBENOMEM\fP で失敗する。 "init" プロセスが終了している PID
+名前空間に新しいプロセスを作成することはできない。 このような状況は、 例えば、 名前空間にいたプロセスに対応する
+\fI/proc/[pid]/ns/pid\fP ファイルに対してオープンしたファイルディスクリプタを使って、 "init"
+プロセスが終了した後にその名前空間に \fBsetns\fP(2) を行った場合に起こり得る。 \fBunshare\fP(2)
+を呼び出した後にも、この状況は起こり得る。 それ以降に \fBfork\fP(2) で作成された最初の子プロセスが終了すると、 それ以降の
+\fBfork\fP(2) の呼び出しは \fBNOMEM\fP で失敗する。
+
+PID 名前空間の他のメンバーは、 "init" プロセスがシグナルハンドラーを設定したシグナルだけを、 "init" プロセスに送信することができる。
+この制限は特権プロセスに対しても適用される。 この制限により、 PID 名前空間の他のメンバーがうっかり "init"
+プロセスを殺してしまうのを防ぐことができる。
+
+同様に、 先祖の名前空間のプロセスは、 "init" プロセスがそのシグナルに対するハンドラーを設定している場合にのみ、 \fBkill\fP(2)
+で説明されている通常のアクセス許可のチェックを経た上で、 子供の PID 名前空間の "init" プロセスにシグナルを送信できる。
+(ハンドラー内では、 \fIsigaction\fP(2) に説明がある \fIsiginfo_t\fP の \fIsi_pid\fP フィールドは 0 になる。)
+\fBSIGKILL\fP と \fBSIGSTOP\fP は例外として扱われ、 これらのシグナルが先祖の PID
+名前空間から送信された場合には強制的に配送される。 これらのシグナルはどちらも "init" プロセルが捕捉することはできない。
+そのため、これらのシグナルに関連付けられた通常のアクション (それぞれ、プロセスの終了とプロセスの強制停止) が実行される。
+
+.\"
+.\" ============================================================
+.\"
+Linux 3.4 以降では、 \fBreboot\fP(2) システムコールを呼び出すと、 シグナルがその名前空間の "init" プロセスに送信される。
+詳細は \fBreboot\fP(2) を参照。
+.SS "ネストされた PID 名前空間"
+PID 名前空間は入れ子にすることができる。 最初の ("root") PID 名前空間以外の各 PID 名前空間は親を持つ。 PID 名前空間の親は
+\fBclone\fP(2) や \fBunshare\fP(2) を使ってその名前空間を作成したプロセスの PID 名前空間である。 したがって、 PID
+名前空間は木構造を構成し、 すべての名前空間は親を辿って行くと、最終的には root 名前空間に辿り着く。
+
+プロセスは、所属する PID 名前空間の他のプロセスから見える。また、 root PID 名前空間に向かう直径の先祖の各 PID
+名前空間のプロセスからも見える。 この場合、「見える」とは、 あるプロセスが、 他のプロセスがプロセス ID
+を指定するシステムコールを使う際に操作の対象にできることを意味する。 逆に、子供 PID 名前空間のプロセスから親や先祖の名前空間のプロセスは見えない。
+あるプロセスは自分自身の PID 名前空間とその子孫の名前空間のプロセスだけが見える (例えば、\fBkill\fP(2) でシグナルを送信したり、
+\fBsetpriority\fP(2) で nice 値を設定したり、など)。
+
+プロセスは、そのプロセスが見える PID 名前空間の階層の各層においてプロセス ID を一つ持ち、 直接の先祖の名前空間を辿ることで通って root
+PID 名前空間に至ることができる。 プロセス ID に対して操作を行うシステムコールは、常に、呼び出し元プロセスの PID 名前空間で見えるプロセス
+ID を使って操作を行う。 \fBgetpid\fP(2) の呼び出しでは、 常に、 プロセスが作成された名前空間に関連付けられた PID を返す。
+
+.\"
+.\" ============================================================
+.\"
+PID 名前空間内のプロセスは名前空間の外部に親プロセスを持つことができる。 例えば、その名前空間の初期プロセス (すなわち PID 1 を持つ
+\fBinit\fP(1) プロセス) の親プロセスは必然的に別の名前空間に属すことになる。 同様に、 あるプロセスが \fBsetns\fP(2)
+を使って子プロセスを PID 名前空間に参加させた場合、 子プロセスは \fBsetns\fP(2) の呼び出し元とは異なる PID 名前空間に属す。
+子プロセスで \fBgetppid\fP(2) を呼び出すと 0 が返される。
+.SS "setns(2) と unshare(2) の動作"
+PID 名前空間のファイルディスクリプタを指定して \fBsetns\fP(2) を呼び出したり、 \fBCLONE_NEWPID\fP フラグ付きで
+\fBunshare\fP(2) を呼び出したりすると、 その結果作成された子プロセスは呼び出し元とは異なる PID 名前空間に置かれる。
+しかし、これらの呼び出しでは呼び出し元プロセスの PID 名前空間は変更されない。 なぜなら、PID 名前空間を変更してしまうと、 呼び出し元が認識する
+(\fBgetpid\fP() が返す) 自分の PID が変わってしまい、 多くのアプリケーションやライブラリが正しく動作しなくなるからである。
+
+別の言い方をすると、 あるプロセスがどの PID 名前空間に所属するかは、 そのプロセスが作成されたときに決定され、 それ以降は変更されることはない。
+いろいろあるが、プロセス間の親子関係には、PID 名前空間の親子関係がそのまま反映されるということだ。
+プロセスの親プロセスは、同じ名前空間にいるか、もしくは直接の親 PID 名前空間にいるかのいずれかである。
+.SS "CLONE_NEWPID の他の CLONE_* フラグとの互換性"
+\fBCLONE_NEWPID\fP はいくつかの他の \fBCLONE_*\fP フラグと組み合わせることができない。
+.IP * 3
+\fBCLONE_THREAD\fP は、 プロセス内のスレッド間で互いにシグナルを送信できるようにするため、 同じ PID 名前空間に属している必要がある。
+同様に、 プロセス内の全スレッドが \fBproc\fP(5) ファイルシステムで見える必要がある。
+.IP *
+\fBCLONE_SIGHAND\fP は、同じ PID 名前空間である必要がある。 さもなければ、
+シグナルが送信された際に、シグナルを送信したプロセスのプロセス ID を意味のある形でエンコードすることができない (\fBsigaction\fP(2) の
+\fIsiginfo_t\fP 型の説明を参照)。 複数の PID 名前空間に属するプロセス間で一つのシグナルキューを共有すると、うまく動かなくなる。
+.IP *
+\fBCLONE_VM\fP は、全スレッドが同じ PID 名前空間に属している必要がある。 なぜなら、 コアダンプの観点から見ると、 2
+つのプロセスが同じアドレス空間を共有していれば、 これらはスレッドであり、コアダンプが一緒に行われるからである。 コアダンプが書き込まれる際に、
+各スレッドの PID がコアダンプに書き込まれる。 もしプロセス ID のいくつかが親 PID 名前空間に属していたとすると、 プロセス ID
+の書き込みは意味を持たなくなってしまう。
+.PP
+まとめると、 \fBCLONE_THREAD\fP, \fBCLONE_SIGHAND\fP, \fBCLONE_VM\fP では技術的な要件として PID
+名前空間が共有されている点がある。 (さらに \fBclone\fP(2) では \fBCLONE_THREAD\fP か \fBCLONE_SIGHAND\fP
+が指定された際には \fBCLONE_VM\fP が指定されている必要がある点にも注意。) したがって、以下のような順序で呼び出しを行うと (エラー
+\fBEINVAL\fP で) 失敗する。
+
+.nf
+ 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 */
+.fi
+.\"
+.\" ============================================================
+.\"
+.SS "/proc と PID 名前空間"
+\fI/proc\fP ファイルシステムは、\fI/proc\fP のマウントを行ったプロセスの PID 名前空間で見えるプロセスだけを表示する。 たとえ、 その
+\fI/proc\fP ファイルシステムが他の名前空間のプロセスから参照されたとしても、そうである。
+
+新しい PID 名前空間を作成した後、 子プロセスが、自身の root ディレクトリを変更し、新しい procfs インスタンスを \fI/proc\fP
+にマウントするのは \fBps\fP(1) などのツールが正しく動作するためにも有用である。 \fBclone\fP(2) の \fIflags\fP 引き数に
+\fBCLONE_NEWNS\fP も指定されて新しいマウント名前空間が同時に作成された場合は、 root ディレクトリを変更する必要はない。 新しい
+procfs インスタンスを \fI/proc\fP にそのままマウントすることができる。
+
+シェルから、コマンドで \fI/proc\fP のマウントを行うには次のようにする。
+
+ $ mount \-t proc proc /proc
+
+.\"
+.\" ============================================================
+.\"
+パス \fI/proc/self\fP に対して \fBreadlink\fP(2) を呼び出すと、 procfs のマウントを行ったプロセスの PID
+名前空間におけるプロセス ID が得られる。 これは調査目的でプロセスが他の名前空間で自身の PID を知りたい場合などに役立つ。
+.SS その他
+プロセス ID が UNIX ドメインソケット経由で別の PID 名前空間のプロセスに渡される場合 (\fBunix\fP(7) の
+\fBSCM_CREDENTIALS\fP の説明を参照)、 プロセス ID は受信プロセスの PID 名前空間での対応する PID 値に翻訳される。
+.SH 準拠
+名前空間は Linux 独自の機能である。
+.SH 例
+\fBuser_namespaces\fP(7) 参照。
+.SH 関連項目
+\fBclone\fP(2), \fBsetns\fP(2), \fBunshare\fP(2), \fBproc\fP(5), \fBcredentials\fP(7),
+\fBcapabilities\fP(7), \fBuser_namespaces\fP(7), \fBswitch_root\fP(8)
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.76 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
OSDN Git Service
