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 February 1, 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_PEERCRED 336Requested via 337.Xr getsockopt 2 338on a 339.Dv SOCK_STREAM 340or 341.Dv SOCK_SEQPACKET 342socket returns credentials of the remote side. 343These will arrive in the form of a filled in 344.Vt xucred 345structure, defined in 346.In sys/ucred.h 347as follows: 348.Bd -literal 349struct xucred { 350 u_int cr_version; /* structure layout version */ 351 uid_t cr_uid; /* effective user id */ 352 short cr_ngroups; /* number of groups */ 353 gid_t cr_groups[XU_NGROUPS]; /* groups */ 354 pid_t cr_pid; /* process id of the sending process */ 355}; 356.Ed 357The 358.Vt cr_version 359fields should be checked against 360.Dv XUCRED_VERSION 361define. 362.Pp 363The credentials presented to the server (the 364.Xr listen 2 365caller) are those of the client when it called 366.Xr connect 2 ; 367the credentials presented to the client (the 368.Xr connect 2 369caller) are those of the server when it called 370.Xr listen 2 . 371This mechanism is reliable; there is no way for either party to influence 372the credentials presented to its peer except by calling the appropriate 373system call (e.g., 374.Xr connect 2 375or 376.Xr listen 2 ) 377under different effective credentials. 378.Pp 379To reliably obtain peer credentials on a 380.Dv SOCK_DGRAM 381socket refer to the 382.Dv LOCAL_CREDS 383socket option. 384.El 385.Sh BUFFERING 386Due to the local nature of the 387.Ux Ns -domain 388sockets, they do not implement send buffers. 389The 390.Xr send 2 391and 392.Xr write 2 393families of system calls attempt to write data to the receive buffer of the 394destination socket. 395.Pp 396The default buffer sizes for 397.Dv SOCK_STREAM 398and 399.Dv SOCK_SEQPACKET 400.Ux Ns -domain 401sockets can be configured with 402.Va net.local.stream 403and 404.Va net.local.seqpacket 405branches of 406.Xr sysctl 3 407MIB respectively. 408Note that setting the send buffer size (sendspace) affects only the maximum 409write size. 410.Pp 411The 412.Ux Ns -domain 413sockets of type 414.Dv SOCK_DGRAM 415are unreliable and always non-blocking for write operations. 416The default receive buffer can be configured with 417.Va net.local.dgram.recvspace . 418The maximum allowed datagram size is limited by 419.Va net.local.dgram.maxdgram . 420A 421.Dv SOCK_DGRAM 422socket that has been bound with 423.Xr bind 2 424can have multiple peers connected 425at the same time. 426The modern 427.Fx 428implementation will allocate 429.Va net.local.dgram.recvspace 430sized private buffers in the receive buffer of the bound socket for every 431connected socket, preventing a situation when a single writer can exhaust 432all of buffer space. 433Messages coming from unconnected sends using 434.Xr sendto 2 435land on the shared buffer of the receiving socket, which has the same 436size limit. 437A side effect of the implementation is that it doesn't guarantee 438that writes from different senders will arrive at the receiver in the same 439chronological order they were sent. 440The order is preserved for writes coming through a particular connection. 441.Sh SEE ALSO 442.Xr connect 2 , 443.Xr dup 2 , 444.Xr fcntl 2 , 445.Xr getsockopt 2 , 446.Xr listen 2 , 447.Xr recvmsg 2 , 448.Xr sendto 2 , 449.Xr setsockopt 2 , 450.Xr socket 2 , 451.Xr CMSG_DATA 3 , 452.Xr intro 4 , 453.Xr sysctl 8 454.Rs 455.%T "An Introductory 4.3 BSD Interprocess Communication Tutorial" 456.%B PS1 457.%N 7 458.Re 459.Rs 460.%T "An Advanced 4.3 BSD Interprocess Communication Tutorial" 461.%B PS1 462.%N 8 463.Re 464