EN JA
UNIX(4)
UNIX(4) FreeBSD Kernel Interfaces Manual UNIX(4)

名称

unixUNIX ドメインプロトコルファミリ

書式

#include < sys/types.h>
#include < sys/un.h>

解説

UNIX ドメインプロトコルファミリは、通常の socket(2) メカニズムを介してローカル (マシンの) プロセス間通信を提供するプロトコルの集まりです。 UNIX ドメインファミリは、 SOCK_STREAM, SOCK_SEQPACKETSOCK_DGRAM ソケットタイプをサポートし、アドレシングにファイルシステムのパス名を使用します。

アドレッシング

UNIX ドメインのアドレスは、多くても 104 の文字の可変長のファイルシステムパス名です。インクルードファイル < sys/un.h> は、次のアドレスを定義しています:

struct sockaddr_un { 
 u_char sun_len; 
 u_char sun_family; 
 char sun_path[104]; 
};

bind(2)UNIX ドメインソケットに名前をバインドすることによって、ファイルシステムにソケットファイルを作成されます。このファイルは、ソケットがクローズされても削除 されません —ファイルを削除するためには、 unlink(2) を使用しなければなりません。

bind(2)connect(2) によって要求される UNIX ドメインアドレスの長さは、 < sys/un.h> で定義されたマクロ SUN_LEN() を使用して計算することができます。 sun_path フィールドは、 SUN_LEN() で使用されるために ヌル 文字で終了していなければなりませんが、終端の ヌル は、アドレスの一部では ありません。

UNIX ドメインプロトコルファミリは、着信メッセージでブロードキャストアドレシングも“ワイルドカード”に適合するどんな形式もサポートしていません。すべてのアドレスは、他の UNIX ドメインソケットの絶対的パス名か相対的パス名です。また、パス名を参照するとき、通常のファイルシステムアクセス制御メカニズムが適用されます。例えば、 connect(2) または sendto(2) の宛先は、書き込み可能でなければなりません。

渡されるファイル記述子

UNIX ドメインソケットは、 sendmsg(2)recvmsg(2)msg 引数で msg_control フィールドの使用を通して UNIX ファイル記述子の通信をサポートしています。

任意の有効な記述子をメッセージで送信できます。渡されるファイル記述子は、インクルードファイル < sys/socket.h> で定義される struct cmsghdr を使用して記述されます。メッセージのタイプは、 SCM_RIGHTS で、メッセージのデータ部分は、渡されるファイル記述子を表す整数の配列です。渡される記述子の数は、メッセージの長さのフィールドによって定義されます。長さのフィールドは、ヘッダのサイズとファイル記述子配列のサイズの合計です。

受信された記述子は、 MSG_CMSG_CLOEXECrecvmsg(2) 呼び出しで渡されるかどうかに依存する dup(fd) または fcntl(fd, F_DUPFD_CLOEXEC, 0) を通して作成されたかのように、送信側の記述子の 複写 です。配信を待っているか、または故意に受信されない記述子は、宛先ソケットがクローズされるとき、システムによって自動的にクローズされます。

ソケットオプション

UNIX ドメインソケットは、 setsockopt(2) で設定され、 getsockopt(2) でテストすることができる多くのソケットオプションをサポートします:
LOCAL_CREDS
このオプションは、 SOCK_DGRAM, SOCK_SEQPACKET または SOCK_STREAM ソケットで有効にされるかもしれません。このオプションは、受信側が recvmsg(2) コントロールメッセージとしてプロセスの資格証明を受信するようなメカニズムを提供します。 cmsghdr 構造体を含むバッファを指す msghdr 構造体の msg_control フィールドは、次の < sys/socket.h> で定義された可変長の sockcred 構造体が後に続きます:

struct sockcred { 
  uid_t sc_uid;  /* 実ユーザ ID */ 
  uid_t sc_euid; /* 実効ユーザ ID */ 
  gid_t sc_gid;  /* 実グループ ID */ 
  gid_t sc_egid; /* 実効グループ ID */ 
  int sc_ngroups; /* 追加グループの数 */ 
  gid_t sc_groups[1]; /* 可変長 */ 
};

SOCKCREDSIZE() マクロは、指定された数のグループのための sockcred 構造体のサイズを計算します。 cmsghdr フィールドには、次の値があります:

cmsg_len = CMSG_LEN(SOCKCREDSIZE(ngroups)) 
cmsg_level = SOL_SOCKET 
cmsg_type = SCM_CREDS

SOCK_STREAMSOCK_SEQPACKET のソケットの資格証明は、最初にソケットから読み込まれたもののみ渡され、次に、システムは、ソケットのオプションをクリアします。

LOCAL_CONNWAIT
SOCK_STREAM ソケットを使用して、このオプションによって connect(2) は、 accept(2) が listen (接続を受け付け) しているソケットで呼び出されるまで、ブロックします。
LOCAL_PEERCRED
SOCK_STREAMgetsockopt(2) によって要求されたソケットは、リモート側の資格証明を返します。これらは、次のように < sys/ucred.h> で定義された xucred 構造体に書き込まれた形式で到達します:

struct xucred { 
  u_int cr_version;  /* 構造体レイアウトバージョン */ 
  uid_t cr_uid;   /* 実効ユーザ ID */ 
  short cr_ngroups;  /* グループの数 */ 
  gid_t cr_groups[XU_NGROUPS]; /* グループ */ 
};

cr_version フィールドは、 XUCRED_VERSION 定義と照合されるべきです。

サーバ ( listen(2) の呼び出し側) に提出された資格証明は、 connect(2) を呼び出したとき、クライアントの資格証明です。クライアント connect(2) の呼び出し側) に提出された資格証明は、 listen(2) を呼び出したとき、サーバの資格証明です。このメカニズムは、信頼できます。異なる有効な資格証明の下で適切なシステムコール (例えば、 connect(2) または listen(2)) を呼び出すことによる場合を除いて、そのピア (相手側) に提出された資格証明に影響を及ぼす、いずれかの当事者 (party) のための方法はありません。

SOCK_DGRAM で信頼されるピア (相手側) の資格証明を得るためには、ソケットは、 LOCAL_CREDS ソケットオプションを参照します。

関連項目

connect(2), dup(2), fcntl(2), getsockopt(2), listen(2), recvmsg(2), sendto(2), setsockopt(2), socket(2), intro(4) An Introductory 4.3 BSD Interprocess Communication Tutorial, PS1, 7. An Advanced 4.3 BSD Interprocess Communication Tutorial, PS1, 8.
March 19, 2013 FreeBSD