Unix Domain Socket File Descriptor Inheritance in Forked Processes

Short answer

None. When a child process inherits a Unix domain socket file descriptor across fork(), no permission check is performed on that inheritance or on subsequent use of the descriptor. Permission checks happen only at the moment a path is resolved — bind() for the listening side and connect() for the client side. An open file descriptor already carries its access rights, so read(), write(), and accept() on an inherited descriptor never re-evaluate the socket file's mode bits or directory permissions.

Where the checks actually live

The confusion in the question comes from conflating two different operations:

• Path-based checks occur when a process names the socket in the filesystem. On Linux, a fresh connect() to a pathname socket requires write permission on the socket file itself, plus search (execute) permission on every directory in the path. These checks use the connecting process's credentials at the time of the call.
• Descriptor-based access involves no path at all. Once a descriptor exists — whether created locally, inherited via fork(), or received via SCM_RIGHTS — the kernel does not re-check filesystem permissions for I/O on it.

So in the daemon architecture you describe — parent binds a listening socket, forks workers — the workers' accept() calls perform no filesystem permission check. The only access control that ever applied was the check on each client's connect(), which happened in the client process, not in your daemon.

Platform differences

The per-connect() check is where implementations diverge:

The portable assumption is that socket-file mode bits are not a reliable access control mechanism. Exact BSD and macOS behavior has varied across releases, so treat enforcement as Linux-specific unless you have verified otherwise on your target version. Note also that Linux abstract-namespace sockets (a leading NUL byte in sun_path) have no filesystem node at all, so file permissions never apply to them.

Practical consequences for your daemon

1. Don't rely on chmod of the socket path for worker isolation. Workers using an inherited listening descriptor are unaffected by later chmod or even unlink() of the path. Unlinking only blocks new pathname connects; existing descriptors keep working — a fact that often surprises daemon-restart logic.
2. Use credential checks after accept() for portable access control. SO_PEERCRED on Linux, LOCAL_PEERCRED on FreeBSD/macOS, or getpeereid() on BSD/macOS give you the peer's UID/GID regardless of filesystem semantics.
3. Inheritance can be a feature. A common hardening pattern runs the bind in a privileged parent and drops privileges in the children, precisely because the inherited descriptor bypasses path checks the child could no longer pass.
4. Set close-on-exec deliberately. Descriptors survive fork() unconditionally but survive exec() only when FD_CLOEXEC is clear. Leaking a listening socket into an exec'd helper is a classic bug; use SOCK_CLOEXEC or fcntl(F_SETFD).

Verifying the behavior

On Linux, bind a socket, chmod 000 the path, and attempt a fresh connect() from a different UID — expect EACCES. Then connect first, fork, and confirm the child can still read and write the inherited descriptor after the path is chmod'd or unlinked. Repeating the first test on macOS or a BSD demonstrates the enforcement difference. strace (Linux) or dtruss (macOS) will show that I/O on inherited descriptors issues no path-based permission syscalls at all.

One caveat: the BSD/macOS side of this comparison is the part most likely to shift between OS releases, so if your deployment targets a specific version, verify there rather than trusting the historical behavior.