Re: [PATCH 2/2] man/man7/landlock.7: Document LANDLOCK_ACCESS_FS_RESOLVE_UNIX (ABI v9)

Alejandro Colomar <[email protected]>
Newsgroups org.kernel.vger.linux-man
Message-ID <agW4yMK6CinJGqXt@devuan>
Hi Günther,

On 2026-05-14T09:04:17+0200, Günther Noack wrote:
> Document the new LANDLOCK_ACCESS_FS_RESOLVE_UNIX filesystem access right,
> which controls lookups of pathname UNIX domain sockets.  Restricts both
> connect(2) and sendmsg(2) with an explicit recipient address to UNIX
> sockets created outside the Landlock domain (same semantics as
> LANDLOCK_SCOPE_* flags).  Denied attempts return EACCES.
> 
> Available since Linux 7.1 (Landlock ABI version 9).
> 
> Signed-off-by: Günther Noack <[email protected]>
> ---
>  man/man7/landlock.7 | 56 +++++++++++++++++++++++++++++++++++++--------
>  1 file changed, 46 insertions(+), 10 deletions(-)
> 
> diff --git a/man/man7/landlock.7 b/man/man7/landlock.7
> index 0e3a11489af2..d0d9c720bfaf 100644
> --- a/man/man7/landlock.7
> +++ b/man/man7/landlock.7
> @@ -139,6 +139,38 @@ whose implementations are safe and return the right error codes
>  .RE
>  .IP
>  This access right is available since the fifth version of the Landlock ABI.
> +.TP
> +.B LANDLOCK_ACCESS_FS_RESOLVE_UNIX
> +Look up pathname UNIX
> +domain sockets
> +.RB ( unix (7)).
> +On UNIX domain sockets,
> +this restricts both calls to
> +.BR connect (2)
> +and
> +.BR sendmsg (2)
> +with an explicit recipient address.
> +.IP
> +This access right only applies to connections to UNIX server sockets

s/only applies/applies only/

> +which were created outside the newly created Landlock domain
> +(e.g., from within a parent domain or from an unrestricted process).
> +Newly created UNIX servers
> +within the same Landlock domain
> +continue to be accessible.
> +In this regard,
> +.B LANDLOCK_ACCESS_FS_RESOLVE_UNIX
> +has the same semantics as the
> +.B LANDLOCK_SCOPE_*

* is variable part, so it should be in italics:

	.BI LANDLOCK_SCOPE_ *

> +flags.
> +.IP
> +If a resolve attempt is denied,

'resolve attempt' seems weird.  Should this be 'resolution attempt'?

> +the operation returns an
> +.B EACCES
> +error,
> +in line with other filesystem access rights
> +(but different to denials for abstract UNIX domain sockets).
> +.IP
> +This access right is available since the ninth version of the Landlock ABI.

I see this is consistent with the rest of the page, but we should change
all of these to use cardinals instead of ordinals (and in digits, not
letters).

>  .P
>  Whether an opened file can be truncated with
>  .BR ftruncate (2)
> @@ -478,6 +510,8 @@ _	_	_
>  \^	\^	LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF
>  _	_	_
>  8	7.0	LANDLOCK_RESTRICT_SELF_TSYNC
> +_	_	_
> +9	7.1	LANDLOCK_ACCESS_FS_RESOLVE_UNIX
>  .TE
>  .P
>  Users should use the Landlock ABI version rather than the kernel version
> @@ -563,7 +597,8 @@ attr.handled_access_fs =
>          LANDLOCK_ACCESS_FS_MAKE_SYM |
>          LANDLOCK_ACCESS_FS_REFER |
>          LANDLOCK_ACCESS_FS_TRUNCATE |
> -        LANDLOCK_ACCESS_FS_IOCTL_DEV;
> +        LANDLOCK_ACCESS_FS_IOCTL_DEV |
> +        LANDLOCK_ACCESS_FS_RESOLVE_UNIX;
>  .EE
>  .in
>  .P
> @@ -578,14 +613,15 @@ and only use the available subset of access rights:
>   * numbers hardcoded to keep the example short.
>   */
>  __u64 landlock_fs_access_rights[] = {
> -    (LANDLOCK_ACCESS_FS_MAKE_SYM  << 1) \- 1,  /* v1                  */
> -    (LANDLOCK_ACCESS_FS_REFER     << 1) \- 1,  /* v2: add "refer"     */
> -    (LANDLOCK_ACCESS_FS_TRUNCATE  << 1) \- 1,  /* v3: add "truncate"  */
> -    (LANDLOCK_ACCESS_FS_TRUNCATE  << 1) \- 1,  /* v4: TCP support     */
> -    (LANDLOCK_ACCESS_FS_IOCTL_DEV << 1) \- 1,  /* v5: add "ioctl_dev" */
> -    (LANDLOCK_ACCESS_FS_IOCTL_DEV << 1) \- 1,  /* v6: same            */
> -    (LANDLOCK_ACCESS_FS_IOCTL_DEV << 1) \- 1,  /* v7: same            */
> -    (LANDLOCK_ACCESS_FS_IOCTL_DEV << 1) \- 1,  /* v8: same            */
> +    (LANDLOCK_ACCESS_FS_MAKE_SYM     << 1) \- 1,  /* v1                     */
> +    (LANDLOCK_ACCESS_FS_REFER        << 1) \- 1,  /* v2: add "refer"        */
> +    (LANDLOCK_ACCESS_FS_TRUNCATE     << 1) \- 1,  /* v3: add "truncate"     */
> +    (LANDLOCK_ACCESS_FS_TRUNCATE     << 1) \- 1,  /* v4: TCP support        */
> +    (LANDLOCK_ACCESS_FS_IOCTL_DEV    << 1) \- 1,  /* v5: add "ioctl_dev"    */
> +    (LANDLOCK_ACCESS_FS_IOCTL_DEV    << 1) \- 1,  /* v6: same               */
> +    (LANDLOCK_ACCESS_FS_IOCTL_DEV    << 1) \- 1,  /* v7: same               */
> +    (LANDLOCK_ACCESS_FS_IOCTL_DEV    << 1) \- 1,  /* v8: same               */
> +    (LANDLOCK_ACCESS_FS_RESOLVE_UNIX << 1) \- 1,  /* v9: add "resolve_unix" */

We should probably use C99 comments (//), to reduce the width, and
alignment issues.

Feel free to send formatting patches for these side issues.


Cheers,
Alex

>  };
>  \&
>  int abi = landlock_create_ruleset(NULL, 0,
> @@ -598,7 +634,7 @@ if (abi == \-1) {
>      perror("Unable to use Landlock");
>      return;  /* Graceful fallback: Do nothing.  */
>  }
> -abi = MIN(abi, 8);
> +abi = MIN(abi, 9);
>  \&
>  /* Only use the available rights in the ruleset.  */
>  attr.handled_access_fs &= landlock_fs_access_rights[abi \- 1];
> -- 
> 2.54.0
> 
> 

-- 
<https://www.alejandro-colomar.es>
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmoFvjQACgkQ64mZXMKQ
wqlNTg/7B8FJ62cEx3kqj71eUimnuBsXlj0lUmqP9DcOMNl92ucOFaKCf72CeNP+
+4++7IloTJoG2HI+a+DMX1GOIafeQgkqAwVSMOBBJJV9lD0LJ6rAzznc61v5VjmC
2n9asNl6c5cQqLNnsaa2UurqQRobGCxspbD95FUOqGOooeJrX0M0lKOoqv+rCxdb
4lNzb6ope7X47VwcUOYqTl37GqMVzPR3Fzwt7RvsK7m3FqS3K/4Q7G6Vb7f0zCfe
V45dfN34rev+69bC4JaeSOzKSwgw6hF9m7g21+GDKbEiMsS09aCS0ucysBj/G+Br
UMJa7V98xQqFqjfAci6OjMeISD74JBSVs4Pt1NUH6umpzT23XAqk+Buess9izmMQ
wQOs9ydlTbnVGJs6tIv7ALkcvmyvwB+NZFAyWrJEx/MrCdxw3+WEw/b9bgRgJTSf
ft8yMzbSpIZjRtC/nZafWSkYmfT+k9eZ1uNHE3jsiLZ8LQK4Yjjqs1E8E21wg3XC
UVOni0A4uk0g0lVxnpnFsfZYIZC4EFnpCDMTe/PA0YXGOaf+cEsgn3C6UXFvdEWM
T6FNKMFm6O4jhw99800GbpfcqFo1+zMhvAijJQ7tBR0T2qJqnVpTthdDFAWiS3wa
BbZPPDkWsYDn6ZTHAI32dTZKclVWhcJ8Jp/FUd88aaZo+xZFCxM=
=Ah9R
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.