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