.\" This man page is Copyright (C) 1999 Andi Kleen <ak@muc.de>.
+.\" and Copyright (C) 2008-2014, Michael Kerrisk <mtk.manpages@gmail.com>
+.\"
+.\" %%%LICENSE_START(VERBATIM_ONE_PARA)
+.\" and Copyright (C) 2008, 2012 Michael Kerrisk <mtk.manpages@gmail.com>
.\" Permission is granted to distribute possibly modified copies
.\" of this page provided the header is included verbatim,
.\" and in case of nontrivial modification author and date
.\" of the modification is added to the header.
+.\" %%%LICENSE_END
.\"
.\" Modified, 2003-12-02, Michael Kerrisk, <mtk.manpages@gmail.com>
.\" Modified, 2003-09-23, Adam Langley
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
-.TH UNIX 7 2012\-05\-10 Linux "Linux Programmer's Manual"
+.\"
+.\" Japanese Version Copyright (c) 1999 Shouichi Saito and
+.\" NAKANO Takeo all rights reserved.
+.\" Translated 1999-12-06, NAKANO Takeo <nakano@apm.seikei.ac.jp>
+.\" based on the work by Shouichi Saito <ss236rx@ymg.urban.ne.jp>
+.\" Updated 2003-01-07, Akihiro MOTOKI <amotoki@dd.iij4u.or.jp>
+.\" Updated 2005-02-21, Akihiro MOTOKI
+.\" Updated 2005-12-26, Akihiro MOTOKI
+.\" Updated 2008-08-08, Akihiro MOTOKI, LDP v3.05
+.\"
+.TH UNIX 7 2014\-12\-31 Linux "Linux Programmer's Manual"
.SH 名前
unix \- ローカルな プロセス間通信用のソケット
.SH 書式
システムのパス名に 結び付けることもできる。さらに Linux では、ファイル
システムに依存しない抽象名前空間 (abstract namespace) もサポートしている。
-有効なタイプを以下に示す。 \fBSOCK_STREAM\fP はストリーム指向のソケットである。
-\fBSOCK_DGRAM\fP はメッセージ境界を保存するデータグラム指向のソケットである
-(ほとんどの UNIX の実装では、UNIX ドメイン・データグラム・ソケットは 常に
-信頼でき、データグラムの並び替えは行わない)。
-\fBSOCK_SEQPACKET\fP はメッセージ境界を保存し、送信された順序でメッセージを
-届ける接続指向ソケット である (Linux 2.6.4 以降で利用できる)。
+UNIX ドメインに指定できるソケットタイプは以下の通りである。 \fBSOCK_STREAM\fP は、 ストリーム指向のソケットで有効である。
+\fBSOCK_DGRAM\fP は、 メッセージ境界を保存するデータグラム指向のソケットで有効である (ほとんどの UNIX の実装では、 UNIX
+ドメイン・データグラム・ソケットは常に信頼でき、 データグラムの並び替えは行わない)。 \fBSOCK_SEQPACKET\fP は、
+メッセージ境界を保存し送信された順序でメッセージを届ける接続指向ソケットで有効である (Linux 2.6.4 以降で利用できる)。
UNIX ドメインソケットでは、補助データを使って ファイルディスクリプタや
プロセスの信任状 (credential) を 送受信することもできる。
.fi
.in
.PP
-\fIsun_family\fP には必ず \fBAF_UNIX\fP が入っている。
+\fIsun_family\fP フィールドには必ず \fBAF_UNIX\fP が入っている。
+
+様々なシステムコール (例えば \fBbind\fP(2), \fBconnect\fP(2), \fBsendto\fP(2)) は入力として
+\fIsockaddr_un\fP 引き数を取る。 他のいくつかのシステムコール (例えば \fBgetsockname\fP(2),
+\fBgetpeername\fP(2), \fBrecvfrom\fP(2), \fBaccept\fP(2)) はこの型の引き数を返す。
-この構造体では 3 種類のアドレスが区別される。
+\fIsockaddr_un\fP 構造体では 3 種類のアドレスが区別される。
.IP * 3
-\fIpathname (パス名)\fP: \fBbind\fP(2) を使って、UNIX ドメインソケットを NULL 終端
-されたファイルシステム上の パス名に結び付けることができる。
-\fBgetsockname\fP(2), \fBgetpeername\fP(2), \fBaccept\fP(2) がソケットのアドレスを
-返す際には、その長さは
-\fIoffsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1\fP
-であり、 \fIsun_path\fP に NULL 終端されたパス名が格納される。
+\fIpathname (パス名)\fP: \fBbind\fP(2) を使って、UNIX ドメインソケットを、
+ヌル終端されたファイルシステム上のパス名に結び付けることができる。 (上述のいずれかのシステムコールにより) ソケットのアドレスが返される際、
+その長さは
+
+ offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1
+
+であり、 \fIsun_path\fP にはヌル終端されたパス名が格納される。 (Linux では、上記の \fBoffsetof\fP() 式は
+\fIsizeof(sa_family_t)\fP の値と同じだが、 他の実装では \fIsun_path\fP の前に他のフィールドが含まれる場合もある。
+そのため、 \fBoffsetof\fP() 式を使う方がより移植性のある方法でアドレス構造体のサイズを知ることができる。)
+.IP
+パス名ソケットの詳細については、後で説明する。
.IP *
.\" There is quite some variation across implementations: FreeBSD
.\" says the length is 16 bytes, HP-UX 11 says it's zero bytes.
\fIunnamed (名前なし)\fP: \fBbind\fP(2) を使ってパス名に結び付けることができないストリーム型のソケットは 名前を持たない。同様に、
-\fBsocketpair\fP(2) で作成される 2 つのソケットも名前を持たない。 \fBgetsockname\fP(2),
-\fBgetpeername\fP(2), \fBaccept\fP(2) が名前なしのソケットのアドレスを返す際には、 その長さは
+\fBsocketpair\fP(2) で作成される 2 つのソケットも名前を持たない。 名前なしのソケットのアドレスを返す際には、 その長さは
\fIsizeof(sa_family_t)\fP であり、 \fIsun_path\fP は検査すべきではない。
.IP *
-\fIabstract (抽象)\fP: 抽象ソケットアドレスは、 \fIsun_path[0]\fP が NULL バイト
-(\(aq\e0\(aq) であることで区別される。この名前空間におけるソケットのアドレス
-は、 \fIsun_path\fP の残りのバイトの、アドレス構造体の指定された長さの範囲で表さ
-れる (名前中の NULL バイトには特別な意味はない)。この名前はファイルシステムの
-パス名とは何の関係もない。 \fBgetsockname\fP(2), \fBgetpeername\fP(2),
-\fBaccept\fP(2) が抽象ソケットのアドレスを返す際には、返される \fIaddrlen\fP は
-\fIsizeof(sa_family_t)\fP より大きく (つまり 2 より大きく)、ソケットの名前は
-\fIsun_path\fP の最初の \fI(addrlen \- sizeof(sa_family_t))\fP バイトに格納される。
-ソケットの抽象名前空間は Linux による拡張であり、移植性はない。
+\fIabstract (抽象)\fP: 抽象ソケットアドレスは、 \fIsun_path[0]\fP がヌルバイト (\(aq\e0\(aq) であることから
+(パス名ソケットから) 区別できる。 この名前空間におけるソケットのアドレスは、 \fIsun_path\fP の残りのバイトの、
+アドレス構造体の指定された長さの範囲で表される (名前中のヌルバイトには特別な意味はない)。 この名前はファイルシステムのパス名とは何の関係もない。
+抽象ソケットのアドレスを返される際には、 返される \fIaddrlen\fP は \fIsizeof(sa_family_t)\fP より大きく (つまり 2
+より大きく)、 ソケットの名前は \fIsun_path\fP の最初の \fI(addrlen \- sizeof(sa_family_t))\fP
+バイトに格納される。 ソケットの抽象名前空間は Linux による拡張であり、移植性はない。
+.SS パス名ソケット
+ソケットにパス名を結びつける際に、 最大限の移植性を持たせ、コーディングを簡単にするためのルールがいくつかある。
+.IP * 3
+\fIsun_path\fP のパス名はヌル終端すべきである。
+.IP *
+終端のヌルバイトを含めたパス名の長さは \fIsun_path\fP の大きさを超えないようにすべきである。
+.IP *
+\fIsockaddr_un\fP 構造体の終わりを示す \fIaddrlen\fP 引き数は最低でも以下の値を持つべきである。
+
+.nf
+ offsetof(struct sockaddr_un, sun_path)+strlen(addr.sun_path)+1
+.fi
+.IP
+もしくは、もっと簡単には、 \fIaddrlen\fP に \fIsizeof(struct sockaddr_un)\fP を指定することもできる。
+.PP
+.\" Linux does this, including for the case where the supplied path
+.\" is 108 bytes
+UNIX ドメインソケットアドレスの扱いが上記のルールに従っていない実装もいくつかある。 (全部ではないが) いくつかの実装では、
+\fIsun_path\fP に文字列終端の NULL がなかった場合に終端の NULL が追加される。
+
+.\" HP-UX
+.\" Modern BSDs generally have 104, Tru64 and AIX have 104,
+.\" Solaris and Irix have 108
+移植性があるアプリケーションを作成する際には、 いくつかの実装では \fIsun_path\fP は 92 バイトしかないという点にも留意しておくとよい。
+
+様々なシステムコール (\fBaccept\fP(2), \fBrecvfrom\fP(2), \fBgetsockname\fP(2),
+\fBgetpeername\fP(2)) がソケットアドレス構造体を返す。 これらのシステムコールが UNIX ドメインソケットに対して呼ばれた際には、
+これらの呼び出しに渡す \fIaddrlen\fP 引き数は上記の説明のように初期化すべきである。
+リターン時には、この引き数にはアドレス構造体の「実際の」サイズが設定される。 呼び出し側ではこの引き数で返された値を確認すべきである。
+返された値が入力値よりも大きい場合、 \fIsun_path\fP に終端の NULL バイトが存在する保証はない (「バグ」を参照)。
.SS ソケットオプション
歴史的な理由により、これらのオプションは たとえ \fBAF_UNIX\fP 固有のオプションであっても \fBSOL_SOCKET\fP 型で指定する。
ソケットファミリーとして \fBSOL_SOCKET\fP を指定すると、 \fBsetsockopt\fP(2) でオプションが設定でき、
セットされていて、まだソケットが接続されていないと、抽象名前空間に他と重なら
ない名前が自動的に生成される。ブール整数値のフラグを取る。
.SS "自動バインド (autobind) 機能"
-.\" i.e. sizeof(short)
+.\" i.e., sizeof(short)
\fBbind\fP(2) 呼び出しで \fIsizeof(sa_family_t)\fP として \fIaddrlen\fP を指定するか、
アドレスに明示的にバインドされていないソケットに対して
\fBSO_PASSCRED\fP ソケットオプションが指定されていた場合、
そのソケットは抽象アドレスに自動的にバインドされる。
-このアドレスは、1 個の NULL バイトの後に、文字集合 \fI[0\-9a\-f]\fP のバイトが
+このアドレスは、1 個のヌルバイトの後に、文字集合 \fI[0\-9a\-f]\fP のバイトが
5 個続く形式である。したがって、自動的にバインドされるアドレス数には
2^20 個という上限が存在する。
(Linux 2.1.15 以降で、自動バインド機能が追加されたときには、
\fIioctl_type\fP には以下を指定できる:
.TP
\fBSIOCINQ\fP
-.\" FIXME http://sources.redhat.com/bugzilla/show_bug.cgi?id=12002,
+.\" FIXME . http://sources.redhat.com/bugzilla/show_bug.cgi?id=12002,
.\" filed 2010-09-10, may cause SIOCINQ to be defined in glibc headers
.\" SIOCOUTQ also has an effect for UNIX domain sockets, but not
.\" quite what userland might expect. It seems to return the number
.TP
\fBECONNREFUSED\fP
\fBconnect\fP(2) により指定されたリモートアドレスが接続待ちソケットではなかった。
-ã\82¿ã\83¼ã\82²ã\83\83ã\83\88ã\82¢ã\83\89ã\83¬ã\82¹ã\81\8cã\82½ã\82±ã\83\83ã\83\88ã\81§ã\81¯ã\81ªã\81\84å ´å\90\88ã\81«ã\82\82ã\81\93ã\81®ã\82¨ã\83©ã\83¼ã\81\8c発生する。
+ã\81\93ã\81®ã\82¨ã\83©ã\83¼ã\81¯ã\82¿ã\83¼ã\82²ã\83\83ã\83\88ã\81®ã\83\91ã\82¹å\90\8dã\81\8cã\82½ã\82±ã\83\83ã\83\88ã\81§ã\81ªã\81\8bã\81£ã\81\9få ´å\90\88ã\81«ã\82\82発生する。
.TP
\fBECONNRESET\fP
リモートソケットが予期しないかたちでクローズされた。
\fBSCM_CREDENTIALS\fP と抽象名前空間は、Linux 2.2 で導入された。 移植性が必要なプログラムでは使うべきではない。 (BSD
由来のシステムの中にも信任状の送受信をサポートしているものがあるが、 その実装の詳細はシステムによって異なる)
.SH 注意
-Linux の実装では、ファイルシステム上から見えるソケットは、それらが置かれてい
-るディレクトリのパーミッションに従う。ソケットの所有者、グループ、パーミッショ
-ンは変更できる。新しいソケットを作るとき、作ろうとするディレクトリに対して プ
-ロセスが書き込みと検索 (実行) 権限を持っていなければ、作成に失敗する。ソケッ
-トオブジェクトに接続するには、 read/write 権限が必要である。この動作は、多く
-の BSD 由来のシステムとは異なっている (BSD では UNIX ドメインソケットに対して
-はパーミッションを無視する)。 移植性の必要なプログラムでは、セキュリティをこ
-の仕様に依存してはならない。
+Linux の実装では、 ファイルシステム上から見えるソケットは、 それらが置かれているディレクトリのパーミッションに従う。 ソケットの所有者、
+グループ、 パーミッションは変更できる。 新しいソケットを作るとき、 作ろうとするディレクトリに対して プロセスが書き込みと検索 (実行)
+権限を持っていなければ、 作成に失敗する。 ソケットオブジェクトに接続するには、 read/write 権限が必要である。 この動作は、 多くの BSD
+由来のシステムとは異なっている (BSD では UNIX ドメインソケットに対してはパーミッションを無視する)。
+移植性の必要なプログラムでは、セキュリティをこの仕様に依存してはならない。
ファイル名を指定してソケットにバインドすると、ファイルシステムにソケットが
生成される。これは必要なくなったときに呼びだしたユーザーが削除しなければ
\fBSOCK_STREAM\fP 上でファイルディスクリプタや信任状を渡すためには、同じ \fBsendmsg\fP(2) や \fBrecvmsg\fP(2)
コールで補助データ以外のデータを少なくとも 1 バイト送信/受信する必要がある。
+.\"
UNIX ドメインのストリーム・ソケットでは、 帯域外データの概念はサポートされない。
+.SH バグ
+.\" The behavior on Solaris is quite similar.
+ソケットをアドレスに結びつける際、 Linux は終端の NULL が \fIsun_path\fP になかった場合に追加する実装の一つである。
+ほとんどの場合、 これは問題にならない。 ソケットアドレスが取得された際、ソケットをバインドしたときに指定したものより 1 バイト長くなるだけである。
+しかしながら、紛らわしい動作が起こる場合が一つある。 ソケットをバインドした際に 108 個の NULL でないバイトを指定した場合、 終端の NULL
+が追加されるとパス名の長さが \fIsizeof(sun_path)\fP を超えてしまう。 結果として、(例えば \fBaccept\fP(2) で)
+ソケットアドレスを取得した際に、 値を取得する呼び出しの入力の \fIaddress\fP 引き数に \fIsizeof(struct
+sockaddr_un)\fP を指定したとすると、 返されるアドレス構造体は \fIsun_path\fP に終端の NULL を「含まない」ことになる。
+
+.\" i.e., traditional BSD
+さらに、 いくつかの実装では、ソケットをバインドする際に終端の NULL が必要ではなく (\fIaddrlen\fP 引き数を使って \fIsun_path\fP
+の長さが判定される)、 このような実装でソケットアドレスを取得する際には、 \fIsun_path\fP に終端の NULL は存在しない。
+
+ソケットアドレスを取得するアプリケーションでは、 \fIsun_path\fP に終端の NULL が存在しないという移植性の問題を、
+パス名の有効なバイト数が以下のようになると事実を考慮することで取り扱うことができる。
+
+.\" The following patch to amend kernel behavior was rejected:
+.\" http://thread.gmane.org/gmane.linux.kernel.api/2437
+.\" Subject: [patch] Fix handling of overlength pathname in AF_UNIX sun_path
+.\" 2012-04-17
+.\" And there was a related discussion in the Austin list:
+.\" http://thread.gmane.org/gmane.comp.standards.posix.austin.general/5735
+.\" Subject: Having a sun_path with no null terminator
+.\" 2012-04-18
+.\"
+.\" FIXME . Track http://austingroupbugs.net/view.php?id=561
+ strnlen(addr.sun_path, addrlen \- offsetof(sockaddr_un, sun_path))
+
+他の方法としては、 アプリケーションがソケットアドレスを取得する際、 取得の呼び出しを行う前に、 大きさが \fIsizeof(struct
+sockaddr_un)+1\fP のバッファーを割り当てることもできる。 取得の呼び出しでは \fIaddrlen\fP に \fIsizeof(struct
+sockaddr_un)\fP を指定すると、 余分な一つの 0 バイトにより \fIsun_path\fP で返される文字列に終端の NULL
+が含まれることが保証される。
+
+.nf
+.in +3
+void *addrp;
+
+addrlen = sizeof(struct sockaddr_un);
+addrp = malloc(addrlen + 1);
+if (addrp == NULL)
+ /* Handle error */ ;
+memset(addrp, 0, addrlen + 1);
+
+if (getsockname(sfd, (struct sockaddr *) addrp, &addrlen)) == \-1)
+ /* handle error */ ;
+
+printf("sun_path = %s\en", ((struct sockaddr_un *) addrp)\->sun_path);
+.in
+.fi
+
+アプリケーションが「パス名ソケット」の節で説明したルールにしたがってパス名を「作成」していれば、 このような分かりにくさは避けることができる。
.SH 例
\fBbind\fP(2) 参照。
\fBrecvmsg\fP(2), \fBsendmsg\fP(2), \fBsocket\fP(2), \fBsocketpair\fP(2), \fBcmsg\fP(3),
\fBcapabilities\fP(7), \fBcredentials\fP(7), \fBsocket\fP(7)
.SH この文書について
-この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.41 の一部
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.76 の一部
である。プロジェクトの説明とバグ報告に関する情報は
http://www.kernel.org/doc/man\-pages/ に書かれている。
OSDN Git Service
