リナックスコマンド

unixのヘルプ・マニュアル

日本語 英語

• help
• man

unix --help

man unix

UNIX(7) Linux Programmer’s Manual UNIX(7) 名前 unix, AF_UNIX, AF_LOCAL - ローカルなプロセス間通信用のソケット 書式 #include #include unix_socket = socket(AF_UNIX, type, 0); error = socketpair(AF_UNIX, type, 0, int *sv); 説明 AF_UNIX (AF_LOCAL とも言われる) ソケットファミリーは、同じマシン上でプ ロセス同士が効率的に通信するために用いられる。伝統的に、Unix ソケットは 、 名前なしにもできるし、 (ソケット型であると印のついた) ファイルシステ ムのパス名に結び付けることもできる。さらに Linux では、ファイルシステム に依存しない抽象名前空間 (abstract namespace) もサポートしている。 有効なタイプは以下の通りである: SOCK_STREAM ストリーム指向のソケット SOCK_DGRAM メ ッ セージ境界を保存するデータグラム指向のソケット (ほとんどの Unix の実装では、Unix ドメイン・データグラム・ソケットは常に信頼 でき、データグラムの並び替えは行わない) SOCK_SEQPACKET (Linux 2.6.4 以降で利用できる) メッセージ境界を保存し、送信され た順序でメッセージを届ける接続指向ソケット Unix ソケットでは、補助データを使ってファイルディスクリプタや プ ロセスの信任状 (credential) を送受信することもできる。 アドレスのフォーマット Unix ドメインソケットのアドレスは以下の構造体で表現される。 #define UNIX_PATH_MAX 108 struct sockaddr_un { sa_family_t sun_family; /* AF_UNIX */ char sun_path[UNIX_PATH_MAX]; /* pathname */ }; sun_family には必ず AF_UNIX が入っている。 この構造体では 3 種類のアドレスが区別される。 * pathname (パス名): bind(2) を使って、Unix ドメインソケットを NULL 終 端されたファイルシステム上のパス名に結び付けることができ る 。 get- sockname(2), getpeername(2), accept(2) がソケットのアドレスを返す際 には、その長さは sizeof(sa_family_t) + strlen(sun_path) + 1 であり、 sun_path に NULL 終端されたパス名が格納される。 * unnamed (名前なし): bind(2) を使ってパス名に結び付けることができない ストリーム型のソケットは名前を持たない。同様に、 socketpair(2) で 作 成 さ れる 2 つのソケットも名前を持たない。 getsockname(2), getpeer- name(2), accept(2) が名前なしのソケットのアドレスを返す際には、そ の 長さは sizeof(sa_family_t) であり、 sun_path は検査すべきではない。 * abstract ( 抽象): 抽象ソケットアドレスは、 sun_path[0] がヌルバイト (’\0’) であることから区別できる。 sun_path の残りの全バイトにより ソ ケ ッ トの「名前」が定義される (名前中のヌルバイトには特別な意味はな い)。この名前はファイルシステムのパス名とは何の関係もない。この名 前 空間におけるソケットのアドレスは、 sun_path の残りのバイトで表される 。 getsockname(2), getpeername(2), accept(2) が抽象ソケットのアド レ ス を 返 す 際 に は、その長さは sizeof(struct sockaddr_un) であり、 sun_path に抽象名前空間の名前が格納される。ソケットの抽象名前空間 は Linux による拡張であり、移植性はない。 ソケットオプション 歴史的な理由により、これらのオプションはたとえ AF_UNIX 固有のオプション であっても SOL_SOCKET 型で指定する。ソケットファミリーとして SOL_SOCKET を 指定すると、 setsockopt(2) でオプションが設定でき、 getsockopt(2) で 取得ができる。 SO_PASSCRED 送信プロセスの補助メッセージとして信任状を受信できるようにする。 このオプションがセットされていて、まだソケットが接続されていない と、抽象名前空間に他と重ならない名前が自動的に生成される。ブール 整数値のフラグを取る。 ソケット API こ の節では、Linux の Unix ドメイン・ソケットでの、ドメイン固有の詳細仕 様とソケット API でサポートされていない機能について説明する。 Unix ドメイン・ソケットでは、帯域外データ (out-of-band data) の 送 信 (send(2) と recv(2) の MSG_OOB フラグ) はサポートされていない。 send(2) MSG_MORE フラグは Unix ドメイン・ソケットではサポートされていな い。 recv(2) の flags 引き数での MSG_TRUNC の使用は Unix ドメイン・ソケッ ト ではサポートされていない。 SO_SNDBUF ソケットオプションは Unix ドメイン・ソケットで効果を持つが、 SO_RCVBUF は効果がない。データグラム・ソケットでは、 SO_SNDBUF の値が出 力データグラムの上限サイズとなる。実際の上限値は、 SO_SNDBUF オプション として設定された値の 2倍 (socket(7) 参照) からオーバヘッドとして使用 さ れる 32 バイトを引いた値となる。 補助メッセージ 補 助データを送受するには、 sendmsg(2) や recvmsg(2) を使用する。歴史的 な理由により、以下に示す補助メッセージの型はたとえ AF_UNIX 固有のもので あ っ ても SOL_SOCKET 型で指定する。これらを送るには、構造体 cmsghdr の cmsg_level フィールドに SOL_SOCKET をセットし、 cmsg_type フィールド に タイプをセットする。詳細は cmsg(3) を見よ。 SCM_RIGHTS 他のプロセスでオープンされたファイルディスクリプタのセットを送受 信する。データ部分にファイルディスクリプタの整数配列が入っている 。渡されたファイルディスクリプタは、あたかも dup(2) で生成された かのように振る舞う。 SCM_CREDENTIALS Unix 信任状を送受信する。これは認証に用いることができる。信任 状 は 、 struct ucred の補助メッセージとして渡される。この構造体は で以下のように定義されている。 struct ucred { pid_t pid; /* process ID of the sending process */ uid_t uid; /* user ID of the sending process */ gid_t gid; /* group ID of the sending process */ }; glibc 2.8 以降では、この構造体の定義を得るためには機能検査マクロ _GNU_SOURCE を定義しなければならない。 送 信 側が指定した信任状は、カーネルがチェックする。実効ユーザー ID が 0 のプロセスには、自分自身以外の値を指定する事が許される。 送 信側は以下の 3 つを指定しなければならない。 1) 自分自身のプロ セス ID (CAP_SYS_ADMIN 権限を持っていない場合)、 2) 自分自身のユ ーザー ID あるいは実効ユーザー ID か保存 set-user-ID (CAP_SETUID 権限を持っていない場合)、 3) 自分自身のグループ ID あるいは実 行 グ ループ ID か保存 set-group-ID (CAP_SETGID を持っていない場合) 。 struct ucred メッセージを受信するためには、ソケッ ト に 対 し SO_PASSCRED オプションを有効にしなくてはならない。 エラー EADDRINUSE 選択したソケットが既に用いられていた。または、ファイルシステムの ソケットオブジェクトが既に存在していた。 ECONNREFUSED listen 状態にないソケットオブジェクトに対して connect(2) が呼 ば れた。リモートソケットが存在していなかった、ファイル名がソケット ではなかった、などのときに起こる。 ECONNRESET リモートソケットが予期しないかたちでクローズされた。 EFAULT ユーザーメモリアドレスが不正。 EINVAL 渡した引数が不正。よくある原因は、渡したアドレスの sun_type フィ ー ルドに AF_UNIX を設定しなかった、行おうとした操作に対してソケ ットの状態が有効ではなかった、など。 EISCONN 既に接続されているソケットに対して connect(2) が呼ばれた。または 、指定したターゲットアドレスが既に接続済みのソケットだった。 ENOMEM メモリが足りない。 ENOTCONN ソケット操作にターゲットアドレスが必要だが、このソケットは接続さ れていない。 EOPNOTSUPP ストリーム指向でないソケットに対してストリーム操作が呼び出された 。または帯域外データオプションを用いようとした。 EPERM 送信者が struct ucred に不正な信任状を渡した。 EPIPE リモートソケットがストリームソケット上でクローズされた。可能な場 合は SIGPIPE も同時に送られる。これを避けるには MSG_NOSIGNAL フ ラグを sendmsg(2) や recvmsg(2) に渡す。 EPROTONOSUPPORT 渡されたプロトコルが AF_UNIX でない。 EPROTOTYPE リ モ ートソケットとローカルソケットのタイプが一致していなかった (SOCK_DGRAM と SOCK_STREAM)。 ESOCKTNOSUPPORT 未知のソケットタイプ。 他にも汎用のソケット層でエラーが起こったり、ファイルシステム上にソケ ッ ト オブジェクトを作ろうとした場合にファイルシステムのエラーが起こること がある。それぞれの詳細は適切な man ページを参照すること。 バージョン SCM_CREDENTIALS と抽象名前空間は、Linux 2.2 で導入された。移植性が必 要 な プログラムでは使うべきではない。 (BSD 由来のシステムの中にも信任状の 送受信をサポートしているものがあるが、その実装の詳細はシステムによっ て 異なる) 注意 Linux の実装では、ファイルシステム上から見えるソケットは、それらが置か れているディレクトリのパーミッションに従う。ソケットの所有者、グルー プ 、 パーミッションは変更できる。新しいソケットを作るとき、作ろうとするデ ィレクトリに対してプロセスが書き込みと検索 (実行) 権限を持っていなけ れ ば 、作成に失敗する。ソケットオブジェクトに接続するには、 read/write 権 限が必要である。この動作は、多くの BSD 由来のシステムとは異なって い る (BSD では Unix ソケットに対してはパーミッションを無視する)。移植性の必 要なプログラムでは、セキュリティをこの仕様に依存してはならない。 ファイル名を指定してソケットにバインドすると、ファイルシステムにソケ ッ ト が生成される。これは必要なくなったときに呼びだしたユーザーが削除しな ければならない (unlink(2) を用いる)。 Unix で通常使われる「背後で閉じる 方 式」が適用される。ソケットはいつでも unlink することができ、最後の参 照がクローズされたときにファイルシステムから削除される。 SOCK_STREAM 上でファイルディスクリプタや信任状を渡すため に は 、 同 じ sendmsg(2) や recvmsg(2) コールで補助データ以外のデータを少なくとも 1 バイト送信/受信する必要がある。 Unix ドメインのストリーム・ソケットでは、帯域外データの概念はサポートさ れない。 例 bind(2) 参照。 関連項目 recvmsg(2), sendmsg(2), socket(2), socketpair(2), cmsg(3), capabili- ties(7), credentials(7), socket(7) Linux 2008-12-01 UNIX(7)

UNIX(7) Linux Programmer’s Manual UNIX(7) NAME unix, AF_UNIX, AF_LOCAL - Sockets for local interprocess communication SYNOPSIS #include #include unix_socket = socket(AF_UNIX, type, 0); error = socketpair(AF_UNIX, type, 0, int *sv); DESCRIPTION The AF_UNIX (also known as AF_LOCAL) socket family is used to communi- cate between processes on the same machine efficiently. Traditionally, Unix sockets can be either unnamed, or bound to a file system pathname (marked as being of type socket). Linux also supports an abstract namespace which is independent of the file system. Valid types are: SOCK_STREAM, for a stream-oriented socket and SOCK_DGRAM, for a datagram-oriented socket that preserves message boundaries (as on most Unix implementations, Unix domain datagram sock- ets are always reliable and don’t reorder datagrams); and (since Linux 2.6.4) SOCK_SEQPACKET, for a connection-oriented socket that preserves message boundaries and delivers messages in the order that they were sent. Unix sockets support passing file descriptors or process credentials to other processes using ancillary data. Address Format A Unix domain socket address is represented in the following structure: #define UNIX_PATH_MAX 108 struct sockaddr_un { sa_family_t sun_family; /* AF_UNIX */ char sun_path[UNIX_PATH_MAX]; /* pathname */ }; sun_family always contains AF_UNIX. Three types of address are distinguished in this structure: * pathname: a Unix domain socket can be bound to a null-terminated file system pathname using bind(2). When the address of the socket is returned by getsockname(2), getpeername(2), and accept(2), its length is sizeof(sa_family_t) + strlen(sun_path) + 1, and sun_path contains the null-terminated pathname. * unnamed: A stream socket that has not been bound to a pathname using bind(2) has no name. Likewise, the two sockets created by socket- pair(2) are unnamed. When the address of an unnamed socket is returned by getsockname(2), getpeername(2), and accept(2), its length is sizeof(sa_family_t), and sun_path should not be inspected. * abstract: an abstract socket address is distinguished by the fact that sun_path[0] is a null byte (’\0’). All of the remaining bytes in sun_path define the "name" of the socket. (Null bytes in the name have no special significance.) The name has no connection with file system pathnames. The socket’s address in this namespace is given by the rest of the bytes in sun_path. When the address of an abstract socket is returned by getsockname(2), getpeername(2), and accept(2), its length is sizeof(struct sockaddr_un), and sun_path contains the abstract name. The abstract socket namespace is a non- portable Linux extension. Socket Options For historical reasons these socket options are specified with a SOL_SOCKET type even though they are AF_UNIX specific. They can be set with setsockopt(2) and read with getsockopt(2) by specifying SOL_SOCKET as the socket family. SO_PASSCRED Enables the receiving of the credentials of the sending process ancillary message. When this option is set and the socket is not yet connected a unique name in the abstract namespace will be generated automatically. Expects an integer boolean flag. Sockets API The following paragraphs describe domain-specific details and unsup- ported features of the sockets API for Unix domain sockets on Linux. Unix domain sockets do not support the transmission of out-of-band data (the MSG_OOB flag for send(2) and recv(2)). The send(2) MSG_MORE flag is not supported by Unix domain sockets. The use of MSG_TRUNC in the flags argument of recv(2) is not supported by Unix domain sockets. The SO_SNDBUF socket option does have an effect for Unix domain sock- ets, but the SO_RCVBUF option does not. For datagram sockets, the SO_SNDBUF value imposes an upper limit on the size of outgoing data- grams. This limit is calculated as the doubled (see socket(7)) option value less 32 bytes used for overhead. Ancillary Messages Ancillary data is sent and received using sendmsg(2) and recvmsg(2). For historical reasons the ancillary message types listed below are specified with a SOL_SOCKET type even though they are AF_UNIX specific. To send them set the cmsg_level field of the struct cmsghdr to SOL_SOCKET and the cmsg_type field to the type. For more information see cmsg(3). SCM_RIGHTS Send or receive a set of open file descriptors from another pro- cess. The data portion contains an integer array of the file descriptors. The passed file descriptors behave as though they have been created with dup(2). SCM_CREDENTIALS Send or receive Unix credentials. This can be used for authen- tication. The credentials are passed as a struct ucred ancil- lary message. Thus structure is defined in as follows: struct ucred { pid_t pid; /* process ID of the sending process */ uid_t uid; /* user ID of the sending process */ gid_t gid; /* group ID of the sending process */ }; Since glibc 2.8, the _GNU_SOURCE feature test macro must be defined in order to obtain the definition of this structure. The credentials which the sender specifies are checked by the kernel. A process with effective user ID 0 is allowed to spec- ify values that do not match its own. The sender must specify its own process ID (unless it has the capability CAP_SYS_ADMIN), its user ID, effective user ID, or saved set-user-ID (unless it has CAP_SETUID), and its group ID, effective group ID, or saved set-group-ID (unless it has CAP_SETGID). To receive a struct ucred message the SO_PASSCRED option must be enabled on the socket. ERRORS EADDRINUSE Selected local address is already taken or file system socket object already exists. ECONNREFUSED connect(2) called with a socket object that isn’t listening. This can happen when the remote socket does not exist or the filename is not a socket. ECONNRESET Remote socket was unexpectedly closed. EFAULT User memory address was not valid. EINVAL Invalid argument passed. A common cause is the missing setting of AF_UNIX in the sun_type field of passed addresses or the socket being in an invalid state for the applied operation. EISCONN connect(2) called on an already connected socket or a target address was specified on a connected socket. ENOMEM Out of memory. ENOTCONN Socket operation needs a target address, but the socket is not connected. EOPNOTSUPP Stream operation called on non-stream oriented socket or tried to use the out-of-band data option. EPERM The sender passed invalid credentials in the struct ucred. EPIPE Remote socket was closed on a stream socket. If enabled, a SIG- PIPE is sent as well. This can be avoided by passing the MSG_NOSIGNAL flag to sendmsg(2) or recvmsg(2). EPROTONOSUPPORT Passed protocol is not AF_UNIX. EPROTOTYPE Remote socket does not match the local socket type (SOCK_DGRAM vs. SOCK_STREAM) ESOCKTNOSUPPORT Unknown socket type. Other errors can be generated by the generic socket layer or by the file system while generating a file system socket object. See the appropriate manual pages for more information. VERSIONS SCM_CREDENTIALS and the abstract namespace were introduced with Linux 2.2 and should not be used in portable programs. (Some BSD-derived systems also support credential passing, but the implementation details differ.) NOTES In the Linux implementation, sockets which are visible in the file sys- tem honor the permissions of the directory they are in. Their owner, group and their permissions can be changed. Creation of a new socket will fail if the process does not have write and search (execute) per- mission on the directory the socket is created in. Connecting to the socket object requires read/write permission. This behavior differs from many BSD-derived systems which ignore permissions for Unix sock- ets. Portable programs should not rely on this feature for security. Binding to a socket with a filename creates a socket in the file system that must be deleted by the caller when it is no longer needed (using unlink(2)). The usual Unix close-behind semantics apply; the socket can be unlinked at any time and will be finally removed from the file system when the last reference to it is closed. To pass file descriptors or credentials over a SOCK_STREAM, you need to send or receive at least one byte of non-ancillary data in the same sendmsg(2) or recvmsg(2) call. Unix domain stream sockets do not support the notion of out-of-band data. EXAMPLE See bind(2). SEE ALSO recvmsg(2), sendmsg(2), socket(2), socketpair(2), cmsg(3), capabili- ties(7), credentials(7), socket(7) COLOPHON This page is part of release 3.22 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/. Linux 2008-12-01 UNIX(7)