Re: [PATCH 2/3] man/man7/landlock.7: Document AF_UNSPEC behaviour and error codes

["Günther Noack" <gnoack3000@gmail.com>]

Nit in patch subject: "behavior" (man pages use US English)

On Thu, Sep 17, 2026 at 09:58:51AM +0200, Matthieu Buffet wrote:
> Current TCP documentation is missing a description of how AF_UNSPEC is
> mapped (depending on operation and address contents) to AF_INET, and the
> error codes synthesized by Landlock.
> 
> Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
> ---
>  man/man7/landlock.7 | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/man/man7/landlock.7 b/man/man7/landlock.7
> index 880dd50582f3..51e63f40052c 100644
> --- a/man/man7/landlock.7
> +++ b/man/man7/landlock.7
> @@ -276,6 +276,24 @@ Bind a TCP socket to a local port.
>  .TP
>  .BR LANDLOCK_ACCESS_NET_CONNECT_TCP "  (since Landlock ABI version 4)"
>  Connect an active TCP socket to a remote port.
> +.P
> +Note on
> +.BR AF_UNSPEC :
> +Calling
> +.BR connect (2)
> +with that address family

I realize this is technically correct, but to a reader who does not
remember the nomenclature of the socket() call in detail, it is
possible to misinterpret "that address family" as referring to TCP,
rather than to "AF_UNSPEC".

connect(AF_UNSPEC) also does not work universally on all socket
families and types (see connect(2)), so the socket that it's being
used with also has an address family that plays a role here.

Maybe simpler to just say "AF_UNSPEC" instead of "that address
family"?

> +can only dissolve existing associations,
> +and as such is always allowed.


> +Calling
> +.BR bind (2)
> +with that address family
> +is treated the same way the network stack treats it:
> +for IPv4 and
> +.B INADDR_ANY
> +it is treated as
> +.BR AF_INET .
> +All other uses of that address family result in the same error codes
> +as when Landlock is not in use.

It's unclear to me how bind() with an AF_UNSPEC family address is
relevant to Landlock sandboxing?  Is this relevant to include?

>  .\"
>  .SS Scope flags
>  These flags enable isolating a sandboxed process from a set of IPC actions.
> -- 
> 2.47.3
> 

I also could not find this change in the kernel documentation, I
assume you plan to copy it there as well?

–Günther