1 .\" Copyright (c) 1991, 1993
2 .\" The Regents of the University of California. All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\" notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\" notice, this list of conditions and the following disclaimer in the
11 .\" documentation and/or other materials provided with the distribution.
12 .\" 3. All advertising materials mentioning features or use of this software
13 .\" must display the following acknowledgement:
14 .\" This product includes software developed by the University of
15 .\" California, Berkeley and its contributors.
16 .\" 4. Neither the name of the University nor the names of its contributors
17 .\" may be used to endorse or promote products derived from this software
18 .\" without specific prior written permission.
20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
32 .\" @(#)unix.4 8.1 (Berkeley) 6/9/93
40 .Nd UNIX-domain protocol family
47 protocol family is a collection of protocols
48 that provides local (on-machine) interprocess
49 communication through the normal
60 file system pathnames for addressing.
63 addresses are variable-length file system pathnames of
64 at most 104 characters.
68 .Bd -literal -offset indent
80 causes a socket file to be created in the file system.
83 removed when the socket is closed \(em
85 must be used to remove the file.
93 can be calculated by the macro
99 field must be terminated by a
101 character to be used with
111 protocol family does not support broadcast addressing or any form
114 matching on incoming messages.
115 All addresses are absolute- or relative-pathnames
119 Normal file system access-control mechanisms are also
120 applied when referencing pathnames; e.g., the destination
129 protocol family is comprised of simple
130 transport protocols that support the
139 sockets also support the communication of
141 file descriptors through the use of the
150 Any valid descriptor may be sent in a message.
151 The file descriptor(s) to be passed are described using a
153 that is defined in the include file
155 The type of the message is
157 and the data portion of the messages is an array of integers
158 representing the file descriptors to be passed.
159 The number of descriptors being passed is defined
160 by the length field of the message;
161 the length field is the sum of the size of the header
162 plus the size of the array of file descriptors.
164 The received descriptor is a
166 of the sender's descriptor, as if it were created with a call to
168 Per-process descriptor flags, set with
172 passed to a receiver.
173 Descriptors that are awaiting delivery, or that are
174 purposely not received, are automatically closed by the system
175 when the destination socket is closed.
177 The effective credentials (i.e., the user ID and group list) of a
180 socket may be obtained using the
183 This may be used by a server to obtain and verify the credentials of
184 its client, and vice versa by the client to verify the credentials
186 These will arrive in the form of a filled in
190 The credentials presented to the server (the
192 caller) are those of the client when it called
194 the credentials presented to the client (the
196 caller) are those of the server when it called
198 This mechanism is reliable; there is no way for either party to influence
199 the credentials presented to its peer except by calling the appropriate
204 under different effective credentials.
207 domain sockets support a number of socket options which can be set with
211 .Bl -tag -width ".Dv LOCAL_CONNWAIT"
213 This option may be enabled on
219 This option provides a mechanism for the receiver to
220 receive the credentials of the process as a
227 structure points to a buffer that contains a
229 structure followed by a variable length
231 structure, defined in
236 uid_t sc_uid; /* real user id */
237 uid_t sc_euid; /* effective user id */
238 gid_t sc_gid; /* real group id */
239 gid_t sc_egid; /* effective group id */
240 int sc_ngroups; /* number of supplemental groups */
241 gid_t sc_groups[1]; /* variable length */
247 macro computes the size of the
249 structure for a specified number
253 fields have the following values:
255 cmsg_len = CMSG_LEN(SOCKCREDSIZE(ngroups))
256 cmsg_level = SOL_SOCKET
257 cmsg_type = SCM_CREDS
259 .It Dv LOCAL_CONNWAIT
262 sockets, this option causes the
264 function to block until
266 has been called on the listening socket.
272 .%T "An Introductory 4.3 BSD Interprocess Communication Tutorial"
277 .%T "An Advanced 4.3 BSD Interprocess Communication Tutorial"