Linux Manual Pages development
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack@google.com>
To: Pedro Holanda <pedroholanda122205@gmail.com>
Cc: "Alejandro Colomar" <alx@kernel.org>,
	"Mickaël Salaün" <mic@digikod.net>,
	"Günther Noack" <gnoack3000@gmail.com>,
	linux-man@vger.kernel.org
Subject: Re: [PATCH] landlock_restrict_self.2, landlock.7: Document LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS
Date: Thu, 12 Nov 2026 18:48:47 +0100	[thread overview]
Message-ID: <avX7_5l-1kjBhhv2@google.com> (raw)
In-Reply-To: <20261111013137.226288-1-pedroholanda122205@gmail.com>

Hello Pedro!

Thanks for the patch!  Please see my comments inline.

On Tue, Nov 10, 2026 at 08:28:40PM -0500, Pedro Holanda wrote:
> Add the LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS flag (Landlock ABI
> version 11), which sets the no_new_privs attribute of the calling
> thread atomically with successful ruleset enforcement, removing the
> need for a prior prctl(PR_SET_NO_NEW_PRIVS) call. Document the flag in
> landlock_restrict_self(2) alongside LANDLOCK_RESTRICT_SELF_TSYNC, and
> add the ABI 11 row to the VERSIONS table in landlock(7).
> 
> Transcribes the kernel documentation added in Justin Suess's ABI 11
> series.
> 
> Signed-off-by: Pedro Holanda <pedroholanda122205@gmail.com>
> Link: https://lore.kernel.org/linux-security-module/20260809154544.1253100-5-utilityemal77@gmail.com/
> Link: https://github.com/landlock-lsm/linux/issues/66
> ---
>  man/man2/landlock_restrict_self.2 | 29 +++++++++++++++++++++++++++++
>  man/man7/landlock.7               |  2 ++
>  2 files changed, 31 insertions(+)
> 
> Note: following up on the man-pages transcription from issue #66, at
> Günther's suggestion. I've left the DESCRIPTION no_new_privs
> precondition and the EPERM entry unchanged; both now have an exception
> via this flag. Happy to refine them here or in a follow-up.
> 
> diff --git a/man/man2/landlock_restrict_self.2 b/man/man2/landlock_restrict_self.2
> index 3b8f897cf..4cfbd1e6a 100644
> --- a/man/man2/landlock_restrict_self.2
> +++ b/man/man2/landlock_restrict_self.2
> @@ -150,6 +150,35 @@ If the calling thread is running with
>  this operation enables
>  .I no_new_privs
>  on the sibling threads as well.
> +.TP
> +.BR LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS "  (since Landlock ABI version 11)"
> +Sets the
> +.I no_new_privs
> +attribute of the calling thread atomically with enforcement of the
> +ruleset.
> +.I no_new_privs
> +is set if and only if the call succeeds;
> +a failed enforcement leaves it unchanged.
> +Because the call sets
> +.I no_new_privs
> +itself,
> +it removes the need for a prior
> +.BR prctl (2)
> +.B PR_SET_NO_NEW_PRIVS
> +call (or
> +.B CAP_SYS_ADMIN
> +use).
> +.IP
> +When combined with
> +.BR LANDLOCK_RESTRICT_SELF_TSYNC ,
> +.I no_new_privs
> +is set on all threads of the process with the same guarantee.
> +.IP
> +Leaving

This is misformatted and it looks like the patch was pasted into the middle of
itself once?  When the patch is formatted correctly, piping it into "git am"
should apply it cleanly.

The way I send patches is with "git send-email FILENAME.patch"; when I did this
the first time, I found the website https://git-send-email.io/ useful for an
overview on how to set this up.

Can you please have a look and resend it as V2?

I have not applied the patch now, but left some review comments below, based on
comparing it with the kernel Landlock documentation [1].


> --- a/man/man2/landlock_restrict_self.2
> +++ b/man/man2/landlock_restrict_self.2
> @@ -150,6 +150,35 @@ If the calling thread is running with
>  this operation enables
>  .I no_new_privs
>  on the sibling threads as well.
> +.TP
> +.BR LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS "  (since Landlock ABI version 11)"
> +Sets the
> +.I no_new_privs
> +attribute of the calling thread atomically with enforcement of the
> +ruleset.

Nit: Please break sentences using "semantic newlines" as it is described in
man-pages(7).  (Rather break after "atomically" than have a single "ruleset" on
its own in a line.)


> +.I no_new_privs
> +is set if and only if the call succeeds;
> +a failed enforcement leaves it unchanged.
> +Because the call sets
> +.I no_new_privs
> +itself,
> +it removes the need for a prior
> +.BR prctl (2)
> +.B PR_SET_NO_NEW_PRIVS
> +call (or
> +.B CAP_SYS_ADMIN
> +use).
> +.IP
> +When combined with
> +.BR LANDLOCK_RESTRICT_SELF_TSYNC ,
> +.I no_new_privs
> +is set on all threads of the process with the same guarantee.

The documentation is factually correct, but you changed the wording compared to
the uapi/linux/landlock.h header.  We normally try to keep both in line so that
we can maintain them in parallel.  Are you planning to update the header
documentation as well?

P.S. I find the "atomically" phrasing very good and clear; for the other
sentences I am less certain that we need to look at it from all the different
angles like that.


> +.IP
> +Leaving
> +.I no_new_privs
> +unset is risky even when Landlock does not require it,
> +as it can allow a sandboxed process to regain privileges;
> +this flag is the recommended way to avoid that.

I find it slightly misleading to say that Landlock does not require
no_new_privs.  Yes, you can technically also enforce Landlock with CAP_SYS_ADMIN
without having no_new_privs, but that is really a fringe use case.  I would drop
this comment and rely on the existing documentation in the DESCRIPTION section
which describes the prerequisite independent of the flag.


Speaking of the DESCRIPTION section -- in the place where it discusses
no_new_privs, that man page section currently states that you must call
prctl(PR_SET_NO_NEW_PRIVS, ...), which now seems worthy of mention, but
technically speaking incorrect.  Would you like to rephrase that as well?  As
far as I can tell that is a place where the man page currently deviates from the
kernel documentation.  The kernel documentation [1] describes the no_new_privs
prerequisite as well, but is much more succinct -- maybe we should use that
phrasing instead?  (We also probably don't need to describe the prctl() call in
that much detail -- we can just link to PR_SET_NO_NEW_PRIVS(2const)
strategically, where that invocation is already discussed.)

[1] https://docs.kernel.org/userspace-api/landlock.html#c.sys_landlock_restrict_self

Other than that, this looks very good, and the part below as well.  Thank you
for looking into it! :)

—Günther

>  .SH RETURN VALUE
>  On success,
>  .BR landlock_restrict_self ()
> diff --git a/man/man7/landlock.7 b/man/man7/landlock.7
> index 006482c94..e8639dcd4 100644
> --- a/man/man7/landlock.7
> +++ b/man/man7/landlock.7
> @@ -534,6 +534,8 @@ _   _       _
>  9      7.1     LANDLOCK_ACCESS_FS_RESOLVE_UNIX
>  _      _       _
>  10     7.2     LANDLOCK_ADD_RULE_QUIET
> +_      _       _
> +11     7.3     LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS
>  .TE
>  .P
>  Users should use the Landlock ABI version rather than the kernel version
> -- 
> 2.53.0
> 
> +.I no_new_privs
> +unset is risky even when Landlock does not require it,
> +as it can allow a sandboxed process to regain privileges;
> +this flag is the recommended way to avoid that.
>  .SH RETURN VALUE
>  On success,
>  .BR landlock_restrict_self ()
> diff --git a/man/man7/landlock.7 b/man/man7/landlock.7
> index 006482c94..e8639dcd4 100644
> --- a/man/man7/landlock.7
> +++ b/man/man7/landlock.7
> @@ -534,6 +534,8 @@ _	_	_
>  9	7.1	LANDLOCK_ACCESS_FS_RESOLVE_UNIX
>  _	_	_
>  10	7.2	LANDLOCK_ADD_RULE_QUIET
> +_	_	_
> +11	7.3	LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS
>  .TE
>  .P
>  Users should use the Landlock ABI version rather than the kernel version
> -- 
> 2.53.0
> 

      reply	other threads:[~2026-11-12 17:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11  1:28 [PATCH] landlock_restrict_self.2, landlock.7: Document LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS Pedro Holanda
2026-11-12 17:48 ` Günther Noack [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=avX7_5l-1kjBhhv2@google.com \
    --to=gnoack@google.com \
    --cc=alx@kernel.org \
    --cc=gnoack3000@gmail.com \
    --cc=linux-man@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=pedroholanda122205@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox