xref: /freebsd/share/man/man4/unix.4 (revision e0c4386e)
1.\" Copyright (c) 1991, 1993
2.\"	The Regents of the University of California.  All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that the following conditions
6.\" are met:
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. Neither the name of the University nor the names of its contributors
13.\"    may be used to endorse or promote products derived from this software
14.\"    without specific prior written permission.
15.\"
16.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
17.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
18.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
19.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
20.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
21.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
22.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
23.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
24.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
25.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
26.\" SUCH DAMAGE.
27.\"
28.Dd June 24, 2022
29.Dt UNIX 4
30.Os
31.Sh NAME
32.Nm unix
33.Nd UNIX-domain protocol family
34.Sh SYNOPSIS
35.In sys/types.h
36.In sys/un.h
37.Sh DESCRIPTION
38The
39.Ux Ns -domain
40protocol family is a collection of protocols
41that provides local (on-machine) interprocess
42communication through the normal
43.Xr socket 2
44mechanisms.
45The
46.Ux Ns -domain
47family supports the
48.Dv SOCK_STREAM ,
49.Dv SOCK_SEQPACKET ,
50and
51.Dv SOCK_DGRAM
52socket types and uses
53file system pathnames for addressing.
54.Sh ADDRESSING
55.Ux Ns -domain
56addresses are variable-length file system pathnames of
57at most 104 characters.
58The include file
59.In sys/un.h
60defines this address:
61.Bd -literal -offset indent
62struct sockaddr_un {
63	u_char	sun_len;
64	u_char	sun_family;
65	char	sun_path[104];
66};
67.Ed
68.Pp
69Binding a name to a
70.Ux Ns -domain
71socket with
72.Xr bind 2
73causes a socket file to be created in the file system.
74This file is
75.Em not
76removed when the socket is closed \(em
77.Xr unlink 2
78must be used to remove the file.
79.Pp
80The length of
81.Ux Ns -domain
82address, required by
83.Xr bind 2
84and
85.Xr connect 2 ,
86can be calculated by the macro
87.Fn SUN_LEN
88defined in
89.In sys/un.h .
90The
91.Va sun_path
92field must be terminated by a
93.Dv NUL
94character to be used with
95.Fn SUN_LEN ,
96but the terminating
97.Dv NUL
98is
99.Em not
100part of the address.
101.Pp
102The
103.Ux Ns -domain
104protocol family does not support broadcast addressing or any form
105of
106.Dq wildcard
107matching on incoming messages.
108All addresses are absolute- or relative-pathnames
109of other
110.Ux Ns -domain
111sockets.
112Normal file system access-control mechanisms are also
113applied when referencing pathnames; e.g., the destination
114of a
115.Xr connect 2
116or
117.Xr sendto 2
118must be writable.
119.Sh CONTROL MESSAGES
120The
121.Ux Ns -domain
122sockets support the communication of
123.Ux
124file descriptors and process credentials through the use of the
125.Va msg_control
126field in the
127.Fa msg
128argument to
129.Xr sendmsg 2
130and
131.Xr recvmsg 2 .
132The items to be passed are described using a
133.Vt "struct cmsghdr"
134that is defined in the include file
135.In sys/socket.h .
136.Pp
137To send file descriptors, the type of the message is
138.Dv SCM_RIGHTS ,
139and the data portion of the messages is an array of integers
140representing the file descriptors to be passed.
141The number of descriptors being passed is defined
142by the length field of the message;
143the length field is the sum of the size of the header
144plus the size of the array of file descriptors.
145.Pp
146The received descriptor is a
147.Em duplicate
148of the sender's descriptor, as if it were created via
149.Li dup(fd)
150or
151.Li fcntl(fd, F_DUPFD_CLOEXEC, 0)
152depending on whether
153.Dv MSG_CMSG_CLOEXEC
154is passed in the
155.Xr recvmsg 2
156call.
157Descriptors that are awaiting delivery, or that are
158purposely not received, are automatically closed by the system
159when the destination socket is closed.
160.Pp
161Credentials of the sending process can be transmitted explicitly using a
162control message of type
163.Dv SCM_CREDS
164with a data portion of type
165.Vt "struct cmsgcred" ,
166defined in
167.In sys/socket.h
168as follows:
169.Bd -literal
170struct cmsgcred {
171  pid_t	cmcred_pid;		/* PID of sending process */
172  uid_t	cmcred_uid;		/* real UID of sending process */
173  uid_t	cmcred_euid;		/* effective UID of sending process */
174  gid_t	cmcred_gid;		/* real GID of sending process */
175  short	cmcred_ngroups;		/* number of groups */
176  gid_t	cmcred_groups[CMGROUP_MAX];	/* groups */
177};
178.Ed
179.Pp
180The sender should pass a zeroed buffer which will be filled in by the system.
181.Pp
182The group list is truncated to at most
183.Dv CMGROUP_MAX
184GIDs.
185.Pp
186The process ID
187.Fa cmcred_pid
188should not be looked up (such as via the
189.Dv KERN_PROC_PID
190sysctl) for making security decisions.
191The sending process could have exited and its process ID already been
192reused for a new process.
193.Sh SOCKET OPTIONS
194.Tn UNIX
195domain sockets support a number of socket options for the options level
196.Dv SOL_LOCAL ,
197which can be set with
198.Xr setsockopt 2
199and tested with
200.Xr getsockopt 2 :
201.Bl -tag -width ".Dv LOCAL_CREDS_PERSISTENT"
202.It Dv LOCAL_CREDS
203This option may be enabled on
204.Dv SOCK_DGRAM ,
205.Dv SOCK_SEQPACKET ,
206or a
207.Dv SOCK_STREAM
208socket.
209This option provides a mechanism for the receiver to
210receive the credentials of the process calling
211.Xr write 2 ,
212.Xr send 2 ,
213.Xr sendto 2
214or
215.Xr sendmsg 2
216as a
217.Xr recvmsg 2
218control message.
219The
220.Va msg_control
221field in the
222.Vt msghdr
223structure points to a buffer that contains a
224.Vt cmsghdr
225structure followed by a variable length
226.Vt sockcred
227structure, defined in
228.In sys/socket.h
229as follows:
230.Bd -literal
231struct sockcred {
232  uid_t	sc_uid;		/* real user id */
233  uid_t	sc_euid;	/* effective user id */
234  gid_t	sc_gid;		/* real group id */
235  gid_t	sc_egid;	/* effective group id */
236  int	sc_ngroups;	/* number of supplemental groups */
237  gid_t	sc_groups[1];	/* variable length */
238};
239.Ed
240.Pp
241The current implementation truncates the group list to at most
242.Dv CMGROUP_MAX
243groups.
244.Pp
245The
246.Fn SOCKCREDSIZE
247macro computes the size of the
248.Vt sockcred
249structure for a specified number
250of groups.
251The
252.Vt cmsghdr
253fields have the following values:
254.Bd -literal
255cmsg_len = CMSG_LEN(SOCKCREDSIZE(ngroups))
256cmsg_level = SOL_SOCKET
257cmsg_type = SCM_CREDS
258.Ed
259.Pp
260On
261.Dv SOCK_STREAM
262and
263.Dv SOCK_SEQPACKET
264sockets credentials are passed only on the first read from a socket,
265then the system clears the option on the socket.
266.Pp
267This option and the above explicit
268.Vt "struct cmsgcred"
269both use the same value
270.Dv SCM_CREDS
271but incompatible control messages.
272If this option is enabled and the sender attached a
273.Dv SCM_CREDS
274control message with a
275.Vt "struct cmsgcred" ,
276it will be discarded and a
277.Vt "struct sockcred"
278will be included.
279.Pp
280Many setuid programs will
281.Xr write 2
282data at least partially controlled by the invoker,
283such as error messages.
284Therefore, a message accompanied by a particular
285.Fa sc_euid
286value should not be trusted as being from that user.
287.It Dv LOCAL_CREDS_PERSISTENT
288This option is similar to
289.Dv LOCAL_CREDS ,
290except that socket credentials are passed on every read from a
291.Dv SOCK_STREAM
292or
293.Dv SOCK_SEQPACKET
294socket, instead of just the first read.
295Additionally, the
296.Va msg_control
297field in the
298.Vt msghdr
299structure points to a buffer that contains a
300.Vt cmsghdr
301structure followed by a variable length
302.Vt sockcred2
303structure, defined in
304.In sys/socket.h
305as follows:
306.Bd -literal
307struct sockcred2 {
308  int	sc_version;	/* version of this structure */
309  pid_t	sc_pid;		/* PID of sending process */
310  uid_t	sc_uid;		/* real user id */
311  uid_t	sc_euid;	/* effective user id */
312  gid_t	sc_gid;		/* real group id */
313  gid_t	sc_egid;	/* effective group id */
314  int	sc_ngroups;	/* number of supplemental groups */
315  gid_t	sc_groups[1];	/* variable length */
316};
317.Ed
318.Pp
319The current version is zero.
320.Pp
321The
322.Vt cmsghdr
323fields have the following values:
324.Bd -literal
325cmsg_len = CMSG_LEN(SOCKCRED2SIZE(ngroups))
326cmsg_level = SOL_SOCKET
327cmsg_type = SCM_CREDS2
328.Ed
329.Pp
330The
331.Dv LOCAL_CREDS
332and
333.Dv LOCAL_CREDS_PERSISTENT
334options are mutually exclusive.
335.It Dv LOCAL_CONNWAIT
336Used with
337.Dv SOCK_STREAM
338sockets, this option causes the
339.Xr connect 2
340function to block until
341.Xr accept 2
342has been called on the listening socket.
343.It Dv LOCAL_PEERCRED
344Requested via
345.Xr getsockopt 2
346on a
347.Dv SOCK_STREAM
348or
349.Dv SOCK_SEQPACKET
350socket returns credentials of the remote side.
351These will arrive in the form of a filled in
352.Vt xucred
353structure, defined in
354.In sys/ucred.h
355as follows:
356.Bd -literal
357struct xucred {
358  u_int	cr_version;		/* structure layout version */
359  uid_t	cr_uid;			/* effective user id */
360  short	cr_ngroups;		/* number of groups */
361  gid_t	cr_groups[XU_NGROUPS];	/* groups */
362  pid_t	cr_pid;			/* process id of the sending process */
363};
364.Ed
365The
366.Vt cr_version
367fields should be checked against
368.Dv XUCRED_VERSION
369define.
370.Pp
371The credentials presented to the server (the
372.Xr listen 2
373caller) are those of the client when it called
374.Xr connect 2 ;
375the credentials presented to the client (the
376.Xr connect 2
377caller) are those of the server when it called
378.Xr listen 2 .
379This mechanism is reliable; there is no way for either party to influence
380the credentials presented to its peer except by calling the appropriate
381system call (e.g.,
382.Xr connect 2
383or
384.Xr listen 2 )
385under different effective credentials.
386.Pp
387To reliably obtain peer credentials on a
388.Dv SOCK_DGRAM
389socket refer to the
390.Dv LOCAL_CREDS
391socket option.
392.El
393.Sh BUFFERING
394Due to the local nature of the
395.Ux Ns -domain
396sockets, they do not implement send buffers.
397The
398.Xr send 2
399and
400.Xr write 2
401families of system calls attempt to write data to the receive buffer of the
402destination socket.
403.Pp
404The default buffer sizes for
405.Dv SOCK_STREAM
406and
407.Dv SOCK_SEQPACKET
408.Ux Ns -domain
409sockets can be configured with
410.Va net.local.stream
411and
412.Va net.local.seqpacket
413branches of
414.Xr sysctl 3
415MIB respectively.
416Note that setting the send buffer size (sendspace) affects only the maximum
417write size.
418.Pp
419The
420.Ux Ns -domain
421sockets of type
422.Dv SOCK_DGRAM
423are unreliable and always non-blocking for write operations.
424The default receive buffer can be configured with
425.Va net.local.dgram.recvspace .
426The maximum allowed datagram size is limited by
427.Va net.local.dgram.maxdgram .
428A
429.Dv SOCK_DGRAM
430socket that has been bound with
431.Xr bind 2
432can have multiple peers connected
433at the same time.
434The modern
435.Fx
436implementation will allocate
437.Va net.local.dgram.recvspace
438sized private buffers in the receive buffer of the bound socket for every
439connected socket, preventing a situation when a single writer can exhaust
440all of buffer space.
441Messages coming from unconnected sends using
442.Xr sendto 2
443land on the shared buffer of the receiving socket, which has the same
444size limit.
445A side effect of the implementation is that it doesn't guarantee
446that writes from different senders will arrive at the receiver in the same
447chronological order they were sent.
448The order is preserved for writes coming through a particular connection.
449.Sh SEE ALSO
450.Xr connect 2 ,
451.Xr dup 2 ,
452.Xr fcntl 2 ,
453.Xr getsockopt 2 ,
454.Xr listen 2 ,
455.Xr recvmsg 2 ,
456.Xr sendto 2 ,
457.Xr setsockopt 2 ,
458.Xr socket 2 ,
459.Xr CMSG_DATA 3 ,
460.Xr intro 4 ,
461.Xr sysctl 8
462.Rs
463.%T "An Introductory 4.3 BSD Interprocess Communication Tutorial"
464.%B PS1
465.%N 7
466.Re
467.Rs
468.%T "An Advanced 4.3 BSD Interprocess Communication Tutorial"
469.%B PS1
470.%N 8
471.Re
472