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 sockets support the communication of
131 file descriptors and process credentials through the use of the
139 The items to be passed are described using a
141 that is defined in the include file
144 To send file descriptors, the type of the message is
146 and the data portion of the messages is an array of integers
147 representing the file descriptors to be passed.
148 The number of descriptors being passed is defined
149 by the length field of the message;
150 the length field is the sum of the size of the header
151 plus the size of the array of file descriptors.
153 The received descriptor is a
155 of the sender's descriptor, as if it were created via
158 .Li fcntl(fd, F_DUPFD_CLOEXEC, 0)
164 Descriptors that are awaiting delivery, or that are
165 purposely not received, are automatically closed by the system
166 when the destination socket is closed.
168 Credentials of the sending process can be transmitted explicitly using a
169 control message of type
171 with a data portion of type
172 .Vt "struct cmsgcred" ,
178 pid_t cmcred_pid; /* PID of sending process */
179 uid_t cmcred_uid; /* real UID of sending process */
180 uid_t cmcred_euid; /* effective UID of sending process */
181 gid_t cmcred_gid; /* real GID of sending process */
182 short cmcred_ngroups; /* number of groups */
183 gid_t cmcred_groups[CMGROUP_MAX]; /* groups */
187 The sender should pass a zeroed buffer which will be filled in by the system.
189 The group list is truncated to at most
195 should not be looked up (such as via the
197 sysctl) for making security decisions.
198 The sending process could have exited and its process ID already been
199 reused for a new process.
202 domain sockets support a number of socket options which can be set with
206 .Bl -tag -width ".Dv LOCAL_CONNWAIT"
208 This option may be enabled on
214 This option provides a mechanism for the receiver to
215 receive the credentials of the process calling
228 structure points to a buffer that contains a
230 structure followed by a variable length
232 structure, defined in
237 uid_t sc_uid; /* real user id */
238 uid_t sc_euid; /* effective user id */
239 gid_t sc_gid; /* real group id */
240 gid_t sc_egid; /* effective group id */
241 int sc_ngroups; /* number of supplemental groups */
242 gid_t sc_groups[1]; /* variable length */
246 The current implementation truncates the group list to at most
252 macro computes the size of the
254 structure for a specified number
258 fields have the following values:
260 cmsg_len = CMSG_LEN(SOCKCREDSIZE(ngroups))
261 cmsg_level = SOL_SOCKET
262 cmsg_type = SCM_CREDS
269 sockets credentials are passed only on the first read from a socket,
270 then the system clears the option on the socket.
272 This option and the above explicit
273 .Vt "struct cmsgcred"
274 both use the same value
276 but incompatible control messages.
277 If this option is enabled and the sender attached a
279 control message with a
280 .Vt "struct cmsgcred" ,
281 it will be discarded and a
282 .Vt "struct sockcred"
285 Many setuid programs will
287 data at least partially controlled by the invoker,
288 such as error messages.
289 Therefore, a message accompanied by a particular
291 value should not be trusted as being from that user.
292 .It Dv LOCAL_CONNWAIT
295 sockets, this option causes the
297 function to block until
299 has been called on the listening socket.
300 .It Dv LOCAL_PEERCRED
305 socket returns credentials of the remote side.
306 These will arrive in the form of a filled in
308 structure, defined in
313 u_int cr_version; /* structure layout version */
314 uid_t cr_uid; /* effective user id */
315 short cr_ngroups; /* number of groups */
316 gid_t cr_groups[XU_NGROUPS]; /* groups */
321 fields should be checked against
325 The credentials presented to the server (the
327 caller) are those of the client when it called
329 the credentials presented to the client (the
331 caller) are those of the server when it called
333 This mechanism is reliable; there is no way for either party to influence
334 the credentials presented to its peer except by calling the appropriate
339 under different effective credentials.
341 To reliably obtain peer credentials on a
359 .%T "An Introductory 4.3 BSD Interprocess Communication Tutorial"
364 .%T "An Advanced 4.3 BSD Interprocess Communication Tutorial"