Linux namespace とは何か(プロセス隔離の仕組み)

[hiramekun]

[claude]

Claude finished @hiramekun's task in 1m 36s —— View job

---

• 既存 issue の重複・関連確認
• Linux namespace についての解説を作成
• タイトル編集
• ラベル付与
• 関連 issue への相互リンク

---

概要

Linux namespace(名前空間)は、1 台のホスト上で動く複数のプロセスに対して、それぞれ別々の「見える世界」を与えるカーネル機能です。PID(プロセス ID)・ネットワーク・マウントポイント・ホスト名などのシステムリソースを namespace ごとに分離することで、あるプロセスからは自分専用の OS が動いているかのように見せかけます。Docker や Kubernetes のコンテナ分離は、この namespace の仕組みを土台にしています。

flowchart TB
    subgraph Host["ホスト OS (Linuxカーネル)"]
        direction TB
        subgraph NS_A["PID namespace: container-A"]
            A1["PID 1 (init相当)"]
            A2["PID 2 (nginx)"]
        end
        subgraph NS_B["PID namespace: container-B"]
            B1["PID 1 (init相当)"]
            B2["PID 2 (app)"]
        end
        Kernel["カーネルから見た実際のPID\n(例: A1=4001, B1=4050 ...)"]
    end

    NS_A -.実体は同じカーネル上.-> Kernel
    NS_B -.実体は同じカーネル上.-> Kernel

Loading

コンテナ A・B はそれぞれ「自分が PID 1 から始まる唯一のプロセスツリー」だと信じていますが、実際にはホストカーネル上の一部のプロセスを namespace という「窓」越しに見ているだけです。

何が嬉しいのか

namespace がない場合、同じホスト上のすべてのプロセスは同じ PID 空間・同じネットワークインターフェース・同じファイルシステムを共有します。これでは、あるプロセスが ps すれば他のプロセスが全部見えてしまいますし、同じポート番号を複数のアプリで使うこともできません。namespace を使うことで、以下のようなメリットが得られます。

• プロセスの隔離による安全性向上:コンテナ内のプロセスからは、ホストや他コンテナのプロセスが見えない・触れない
• ネットワークの独立:コンテナごとに別々の IP アドレス・ポート空間を持てるため、複数のコンテナで同じポート(例: 8080)を衝突なく使える
• ファイルシステムの隔離:コンテナ内で / を変更・削除しても、ホストや他コンテナのファイルシステムには影響しない
• 軽量な仮想化:VM のようにハードウェアごとエミュレートする必要がなく、1 つのカーネルを共有しながらプロセス単位で隔離できるため起動が高速で低オーバーヘッド

具体例として、Docker で docker run すると、内部的に clone() や unshare() システムコールで新しい namespace 群が作られ、コンテナプロセスはそこに閉じ込められます。これにより「コンテナの中からは自分だけの Linux マシンに見える」体験が実現されています。

詳細

namespace の種類

Linux には以下の種類の namespace があります(カーネルバージョンにより追加されています)。

種類	フラグ	分離対象
PID	CLONE_NEWPID	プロセス ID 空間(自分が PID 1 に見える)
Network (net)	CLONE_NEWNET	ネットワークインターフェース・ルーティングテーブル・ポート
Mount (mnt)	CLONE_NEWNS	マウントポイント(ファイルシステムのビュー)
UTS	CLONE_NEWUTS	ホスト名・ドメイン名
IPC	CLONE_NEWIPC	System V IPC・POSIX メッセージキュー
User	CLONE_NEWUSER	UID/GID のマッピング(namespace 内で root でもホストでは非特権ユーザ、という分離が可能)
Cgroup	CLONE_NEWCGROUP	プロセスから見える cgroup のルートディレクトリ
Time	CLONE_NEWTIME	システム起動時刻・単調クロックのオフセット(比較的新しい)

なお、#64 で扱った cgroup は「リソースを"どれだけ"使えるかを制限する」機能であり、namespace は「"何が"見えるかを分離する」機能です。両者は役割が異なりますが、Docker などのコンテナ実装ではこの 2 つを組み合わせて「軽量な隔離環境」を作っています。

仕組み・使い方

namespace はカーネルの以下の 3 つの主要なシステムコールで操作します。

• clone(2):新しいプロセスを作成すると同時に、指定したフラグ(CLONE_NEWPID など)の namespace も新規作成してそのプロセスを所属させる
• unshare(2):既存のプロセスを、現在所属している namespace から切り離して新しい namespace に移す
• setns(2):既存の namespace に、あとから別プロセスを参加させる(nsenter コマンドの実装で使われる)

コマンドラインから手軽に試すこともできます。

# 新しい PID / mount / UTS namespace 上で bash を起動する
sudo unshare --pid --mount --uts --fork bash

# namespace 内で hostname を変えてもホストには影響しない
hostname container-test
ps aux  # PID 1 から始まる自分だけのプロセスツリーが見える

# 実行中プロセスの namespace 一覧を確認する
ls -l /proc/<PID>/ns/

# 別プロセスの namespace に入る(例: PID 1234 のネットワーク namespace)
sudo nsenter --target 1234 --net bash

/proc/<PID>/ns/ 以下のシンボリックリンクの inode 番号が同じであれば、そのプロセス同士は同じ namespace を共有しています。docker exec や kubectl exec がコンテナ内でコマンドを実行できるのも、内部的には setns() でそのコンテナの namespace に入っているためです。

注意点

• namespace はあくまで「見え方」の分離であり、カーネル自体は 1 つを共有しているため、カーネル脆弱性を突かれると namespace を越えて影響が及ぶ可能性があります(VM ほど強固な隔離ではない)
• User namespace を使わない設定では、コンテナ内の root(UID 0)はホストの root と同一 UID として扱われるため、コンテナ脱出(コンテナブレイクアウト)のリスクが相対的に高まります。rootless コンテナや user namespace の活用はこのリスクを下げる手段の一つです
• namespace はプロセス単位に紐付くため、あるプロセスが所属する namespace 内で最後のプロセスが終了すると、そのプロセス専用に作られた namespace 自体も(bind mount などで参照が残っていなければ)破棄されます

参考リンク

• namespaces(7) — Linux manual page
• unshare(2) — Linux manual page
• clone(2) — Linux manual page
• setns(2) — Linux manual page
• Docker docs: Namespaces

関連ノート

• cgroup とは何か(Linux のリソース制限の仕組み) #64 cgroup とは何か(Linux のリソース制限の仕組み) — cgroup とは何か(Linux のリソース制限の仕組み) #64 : namespace が「何が見えるか」を分離するのに対し、cgroup は「どれだけ使えるか」を制限する、コンテナ隔離のもう一方の柱

[claude]

関連ノート: #66

[hiramekun]

@claude namespaceの種類（TYPE）とはなんですか？見える世界を分離するものの対象がいくつかの種類に分類できるということでしょうか

[hiramekun]

@claude namespaceの種類（TYPE）とはなんですか？見える世界を分離するものの対象がいくつかの種類に分類できるということでしょうか

[claude]

はい、その理解で合っています。

「namespace の種類」というのは、まさに「見える世界を分離する」ときの分離対象ごとにカーネル機能が分かれている、という意味です。namespace という仕組みは1つですが、それが「何を隔離するか」によって PID・Network・Mount・UTS・IPC・User・Cgroup・Time という8つの種類(カテゴリ)に分類されています。

コメント中の表で言うと、

• 「種類」列 = 隔離対象のカテゴリ名(例: PID namespace)
• 「フラグ」列 = そのnamespaceを作るときに clone() / unshare() に渡すシステムコールの定数(例: CLONE_NEWPID)
• 「分離対象」列 = 実際に何が別々に見えるようになるか(例: プロセスID空間)

具体的にイメージすると、1つのプロセスは通常これら8種類の namespace すべてに同時に所属しています。例えばあるコンテナプロセスは、

• PID namespace: このコンテナ専用のプロセスID空間に所属(自分がPID 1に見える)
• Network namespace: このコンテナ専用のネットワークインターフェース・IPアドレスに所属
• Mount namespace: このコンテナ専用のファイルシステムのマウント状態に所属

というように、「種類ごとに別々のnamespaceに所属できる」のがポイントです。実際 /proc//ns/ を見ると、pid・net・mnt・uts・ipc・user・cgroup・time という8つのシンボリックリンクが並んでいて、これはそのプロセスが「どのnamespaceに所属しているか」を種類別に示しています。

$ ls -l /proc/1234/ns/
lrwxrwxrwx 1 root root 0 ... cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 ... ipc -> 'ipc:[4026531839]'
lrwxrwxrwx 1 root root 0 ... mnt -> 'mnt:[4026531840]'
lrwxrwxrwx 1 root root 0 ... net -> 'net:[4026532000]'
lrwxrwxrwx 1 root root 0 ... pid -> 'pid:[4026531836]'
lrwxrwxrwx 1 root root 0 ... user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 ... uts -> 'uts:[4026531838]'

Docker がコンテナを作るときは、この8種類のうち必要なものだけ新規に作成し(例えばデフォルトでは cgroup namespace は作らない設定になっていることもあります)、それ以外はホストのnamespaceをそのまま使う、といった選択的な組み合わせも可能です。つまり「全部まとめて1つの隔離」ではなく、「種類ごとに独立してON/OFFできる隔離の集合」というのがnamespaceの実態です。