Files
freebsd/lib/libsys
John Ericson 6563dcb6b1 unix: allow connectat(2) to name the peer socket by descriptor
Accept an empty `sun_path` when `fd` is not `AT_FDCWD`: the descriptor
then names the peer unix socket directly, instead of being the starting
directory for a pathname lookup.  The held file reference keeps the peer
PCB stable, playing the role `unp_vp_mtxpool` plays in the pathname
path.

The descriptor must carry `CAP_CONNECTAT` and refer to an `AF_UNIX`
socket (`EPROTOTYPE` otherwise, `ENOTSOCK` for non-sockets).  As with a
pathname, a stream/seqpacket peer must be listening.  No filesystem
permission or MAC vnode check applies on this path: possession of the
descriptor is the authorization, as with descriptor passing.

Note this makes it possible to connect a datagram socket to an unbound
peer, which no pathname could previously name.

`connect(2)` and the implicit-connect send path pass `AT_FDCWD` and
still reject an empty path with `EINVAL`.

The `unp_sun_path()` call is hoisted out of `unp_connectat()` because the
early exit conditions for the two system calls (`connect(2)` and
`connectat(2)`) are slightly different.

Additionally, support `/dev/fd/<N>`. In a world with `connectat(2)`,
this is largely overkill, but this also allows me to add support for
direct peer connections with plain `connect(2)`. I think that is a wise
choice because this will allow me to propose this functionality for
Linux too without a new system call (saving that conversation for
later). Ultimately, I want to see multiple operating systems support
this to foster broader userland adoption, which should benefit everyone
including FreeBSD --- it's nicer if more 3rd party in addition to 1st
party software uses the new kernel functionality. Therefore, I hope this
additional feature is also acceptable.

Signed-off-by: John Ericson <[email protected]>
Assisted-by: Claude Code (Claude Opus 4.8 and Fable 5)

Reviewed by:	markj
MFC after:	2 months
Differential Revision:	https://reviews.freebsd.org/D58405
2026-08-10 17:31:22 +00:00
..
2026-03-31 13:13:02 -04:00
…
…
2025-06-24 17:26:40 +01:00
2025-06-24 17:26:40 +01:00
…
…
…
…
…
…
…
…
…
2026-05-24 20:02:06 +03:00
…
2024-09-20 11:37:02 -03:00
…
2024-09-20 11:37:02 -03:00
…
…
…
…
…
2026-07-06 12:50:51 +00:00
2026-05-07 11:57:03 +02:00
2025-12-29 14:25:23 -05:00
…
…
2026-07-27 12:26:41 +02:00
…
2024-04-16 17:48:07 +01:00
…
…
2024-02-08 19:50:32 +00:00
…
2024-10-14 10:26:17 -07:00
2026-07-08 01:03:53 +03:00
…
2025-07-23 12:37:44 -04:00
…
…
…
…
…
…
…
…
…
…
…
…
…
2025-06-12 12:25:31 -06:00
…
2026-04-04 09:30:30 +03:00
…
…
2026-07-20 23:19:12 +03:00
…
2024-03-01 20:36:39 -07:00
2025-11-04 14:23:20 -05:00
2026-07-12 01:04:43 +03:00
2026-01-25 17:54:15 +02:00
…
…
2024-11-13 19:32:04 -05:00
…
…
…
…
2025-06-24 15:24:04 -07:00
…
…
…
…
…
…
2026-03-11 16:38:34 +02:00
…
2024-02-08 19:50:32 +00:00
2026-02-02 16:54:54 +00:00
2024-09-21 05:25:15 -06:00
2026-07-08 01:03:53 +03:00
2025-04-15 00:03:19 +02:00
…
…
…
2026-07-08 01:03:53 +03:00
2025-05-31 17:55:24 +03:00
2025-06-12 12:25:31 -06:00
…
…
2024-02-08 19:50:32 +00:00
…
…
…
…