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