Unix Domain Socket File Descriptor Inheritance in Forked Processes

Unix Domain Socket File Descriptor Inheritance in Forked Processes

Unix domain sockets provide efficient inter-process communication through filesystem-based addressing, where the socket file serves as both address and endpoint. When a process creates a Unix domain socket and then forks, the child process inherits the file descriptor by default. However, the behavior of socket state and connection handling during fork operations presents unresolved questions about resource management and process isolation.

The socket file's lifecycle is tied to the creating process, with unlink() removing the socket and closing it. Yet the interaction between fork(), exec(), and socket file descriptor inheritance across different Unix implementations requires clarification. Specifically, when multiple processes share a socket file descriptor through inheritance, the permission model and access control mechanisms may not behave as expected.

The core uncertainty lies in whether socket file permissions are re-evaluated for each connection attempt from inherited file descriptors, or if the original permission check at socket creation time persists. This becomes particularly relevant in daemon architectures where the parent process creates a listening socket, forks workers, and expects consistent access control behavior across all child processes.

Which specific permission checks apply when a child process attempts to connect to a Unix domain socket through an inherited file descriptor, and how do these differ between Linux, BSD, and macOS implementations?