Unixドメインソケットとfd受け渡し

Unixドメインソケットとは何か

Unixドメインソケット（AF_UNIX、別名 AF_LOCAL）は、同一ホスト内のプロセス間 で双方向にデータをやり取りするための通信路です。APIはネットワークソケットと完全に同一で、socket(AF_UNIX, type, 0) で生成し、bind/listen/accept（または connect）で接続を確立し、read/write や sendmsg/recvmsg でやり取りします。

決定的な違いは、TCP/IPスタックを一切通さない ことです。ネットワークソケットがチェックサム・順序制御・輻輳制御・ルーティングを経由するのに対し、Unixドメインソケットは送信側のバッファから受信側のカーネルバッファへ データをコピーするだけ で完結します。アドレスの解決もポート割り当ても要らず、ループバック（127.0.0.1）経由のTCPより明確に低レイテンシ・高帯域になります。同一ホスト内通信における定番が他IPCを差し置いてこれである理由は、IPCの設計比較 で論じたとおり、双方向・多重化・後述のfd受け渡しを1つのAPIで束ねている点にあります。

3つの型：ストリーム・データグラム・シーケンスドパケット

Unixドメインソケットは3種類のソケット型を選べ、メッセージ境界の扱いが異なります。

ネットワークのUDPと違い、AF_UNIX の SOCK_DGRAM は カーネル内転送なのでパケットが失われません（バッファが満杯なら送信側がブロックまたは EAGAIN で待たされるだけ）。境界を保ちたいがコネクション指向の管理（接続/切断の検知）も欲しい場合は SOCK_SEQPACKET が最適で、後述のfd受け渡しを伴う制御プロトコルでは境界保持が効くため選ばれることが多い型です。

名前空間：パス名 vs abstract socket

サーバー側がアドレスに bind する際、struct sockaddr_un の sun_path をどう埋めるかで2つの名前空間に分かれます。

struct sockaddr_un {
    sa_family_t sun_family;    /* AF_UNIX */
    char        sun_path[108]; /* パス名 or 抽象名 */
};

• パス名ソケット（pathname）: sun_path に /run/foo.sock のようなパスを入れる。bind するとファイルシステム上にソケット型の特殊ファイルが作られ、クライアントは同じパスへ connect する。ディレクトリとファイルのパーミッションでアクセス制御 できる反面、プロセス終了後もファイルが残るため明示的な unlink が要る（残骸があると次回 bind が EADDRINUSE で失敗する）。
• abstract socket（抽象名前空間、Linux固有）: sun_path[0] を ヌルバイト（\0）にして 残りを名前として使う。ファイルシステムに痕跡を残さず、全fdが閉じた瞬間に自動消滅 するので unlink も後始末も不要。名前の衝突管理が要らないコンテナや一時的なデーモンで重宝します。

SCM_RIGHTS：fdそのものを渡す

Unixドメインソケットが他のIPCと一線を画す能力が、ファイルディスクリプタの受け渡し です。通常のデータとは別に、sendmsg/recvmsg の 補助データ（ancillary data、別名 control message） に SCM_RIGHTS というレベルでfd配列を載せて送ります。

/* 送信側：fd を1つ補助データに載せる */
struct msghdr msg = {0};
char buf[1] = {'F'};                 /* 通常データは最低1バイト要る */
struct iovec iov = { buf, sizeof(buf) };
msg.msg_iov = &iov;
msg.msg_iovlen = 1;

char cmsgbuf[CMSG_SPACE(sizeof(int))];
msg.msg_control = cmsgbuf;
msg.msg_controllen = sizeof(cmsgbuf);

struct cmsghdr *cmsg = CMSG_FIRSTHDR(&msg);
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type  = SCM_RIGHTS;
cmsg->cmsg_len   = CMSG_LEN(sizeof(int));
memcpy(CMSG_DATA(cmsg), &fd_to_send, sizeof(int)); /* 送るfd番号 */

sendmsg(sock, &msg, 0);

ここで本質的に重要なのは、渡されるのはfd「番号」ではなく、その番号が指すカーネル内のオブジェクト だという点です。具体的には ファイルディスクリプタテーブル のエントリが指す open file description（カーネル内の struct file）への参照が複製されます。

• 受信側では、recvmsg時に 新しいfd番号がそのプロセスで自動的に割り当てられ、補助データから読み出せます。送信側の番号（例：3）と受信側の番号（例：7）は無関係で構いません。
• 複製されるのは参照なので、送信側と受信側は 同じ open file description を共有 します。つまり ファイルオフセット・O_NONBLOCK などのステータスフラグ・ファイルロックの所有を共有 します。一方が lseek で位置を動かせば他方にも見えます。これは dup を別プロセス越しに行ったのと同じ意味で、fork 後の親子がfdを共有するのと同じ構造です。
• ソケット・パイプ・通常ファイル・eventfd・epoll fd・memfd など、fdで表せるものは何でも渡せます。

アクセス権の移譲という意味

fd受け渡しの真価は、アクセス権そのものを移譲できる ことにあります。open file descriptionは「openした瞬間の権限チェックの結果」を保持しています。Unixでは パーミッションチェックはopen時に1回だけ 行われ、以後の read/write ではfdが有効であれば再チェックされません。

この性質とfd受け渡しを組み合わせると、強力な権限分離パターンが成立します。

特権プロセス（root）            非特権ワーカー（nobody）
  open("/etc/secret", O_RDONLY)
  → fd が「読める権利」を内包
  sendmsg(SCM_RIGHTS, fd) ─────→ recvmsg → 新fd取得
                                  read(新fd)  ← root権限なしでも読める

ワーカーは自分の権限では /etc/secret を open できなくても、特権プロセスがopen済みのfdを受け取れば中身を読めます。逆方向にも使え、特権プロセスが特権ポート（1024未満）を bind した listening socket をワーカーへ配り、複数ワーカーで accept を分担させる構成（古典的なpre-fork型サーバーやsystemdのsocket activation）が組めます。

受け渡しの落とし穴と接続相手の確認

fd受け渡しには実装上の罠がいくつかあります。第一に、補助データの送受信には通常データが最低1バイト必要 です。iovec を空にして補助データだけ送ろうとすると、受信側で正しく受け取れないことがあるため、ダミーの1バイトを必ず添えます。第二に、1メッセージで複数のfdをまとめて渡せます（SCM_RIGHTS のデータ部にint配列を並べる）が、受信バッファが足りないと一部だけ受信し残りがリークします。

そしてabstract socketのようにパーミッションで守れない場合、接続してきた相手が信頼できるか を確かめる必要があります。Linuxでは getsockopt(SO_PEERCRED) で接続相手の PID・UID・GID をカーネルから直接取得できます。これはアプリが自己申告する値ではなく カーネルが接続確立時に記録した検証済みの値 なので偽装できません。SCM_RIGHTS を悪用されないためには、fdを送る前にこのpeer credentialで相手を認証するのが定石です。

まとめ