Linux Security Modules development
 help / color / mirror / Atom feed
From: bot+bpf-ci@kernel.org
To: utilityemal77@gmail.com,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,kpsingh@kernel.org,paul@paul-moore.com,mic@digikod.net,viro@zeniv.linux.org.uk,brauner@kernel.org,kees@kernel.org
Cc: gnoack@google.com,jack@suse.cz,song@kernel.org,yonghong.song@linux.dev,martin.lau@linux.dev,m@maowtm.org,bpf@vger.kernel.org,linux-security-module@vger.kernel.org,linux-kernel@vger.kernel.org,utilityemal77@gmail.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,clm@meta.com,ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next 05/13] landlock: Factor the credential restriction out of landlock_restrict_self()
Date: Fri, 31 Jul 2026 22:24:04 +0000 (UTC)	[thread overview]
Message-ID: <ea9b8de8b22eb98e115d87edf25dbf6793b5b00aadc9cb62ca09402e689545d8@mail.kernel.org> (raw)
In-Reply-To: <20260731022047.189137-6-utilityemal77@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6709 bytes --]

> diff --git a/security/landlock/cred.c b/security/landlock/cred.c
> index cc419de75cd6b..13b3952c31c57 100644
> --- a/security/landlock/cred.c
> +++ b/security/landlock/cred.c

[ ... ]

> @@ -8,14 +8,114 @@
>   */
>
>  #include <linux/binfmts.h>
> +#include <linux/bits.h>
>  #include <linux/cred.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
>  #include <linux/lsm_hooks.h>
> +#include <uapi/linux/landlock.h>
>
>  #include "common.h"
>  #include "cred.h"
> +#include "domain.h"
>  #include "ruleset.h"
>  #include "setup.h"

[ ... ]

> +int landlock_prepare_restriction(
> +	const struct landlock_cred_security *const llcred,
> +	struct landlock_ruleset *const ruleset, const u32 flags,
> +	struct landlock_restriction *const restriction)
> +{
> +#ifdef CONFIG_AUDIT
> +	/* Translates "off" and "on" flags to booleans. */
> +	const bool log_same_exec =
> +		!(flags & LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF);
> +	const bool log_new_exec =
> +		!!(flags & LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON);
> +	const bool log_subdomains =
> +		!(flags & LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF);
> +	const bool prev_log_subdomains = !llcred->log_subdomains_off;
> +#endif /* CONFIG_AUDIT */
> +
> +	*restriction = (struct landlock_restriction){};
> +
> +#ifdef CONFIG_AUDIT
> +	restriction->log_subdomains_off = !prev_log_subdomains ||
> +					  !log_subdomains;
> +#endif /* CONFIG_AUDIT */
> +
> +	if (!ruleset)
> +		return 0;
> +
> +	restriction->domain = landlock_merge_ruleset(llcred->domain, ruleset);
> +	if (IS_ERR(restriction->domain)) {
> +		const int err = PTR_ERR(restriction->domain);
> +
> +		restriction->domain = NULL;
> +		return err;
> +	}
> +
> +#ifdef CONFIG_AUDIT
> +	restriction->domain->hierarchy->log_same_exec = log_same_exec;
> +	restriction->domain->hierarchy->log_new_exec = log_new_exec;
> +	if ((!log_same_exec && !log_new_exec) || !prev_log_subdomains)
> +		restriction->domain->hierarchy->log_status =
> +			LANDLOCK_LOG_DISABLED;
> +#endif /* CONFIG_AUDIT */
> +
> +	return 0;
> +}

This isn't a bug, but would keeping the merged domain in a local (as the
pre-refactor new_dom did) and only storing it into restriction->domain on
success read a bit closer to the surrounding landlock code, and let the
explicit NULL reset go away?

The merged domain is only ever referred to through restriction->domain:
five uses in the error handling and three restriction->domain->hierarchy->...
chains for the audit configuration. The code this was factored out of used
a local for exactly this (struct landlock_ruleset *const new_dom =
landlock_merge_ruleset(...), then new_dom->hierarchy->log_same_exec = ...),
and the neighbouring landlock code consistently uses that shape (e.g.
security/landlock/syscalls.c: ruleset = landlock_get_ruleset_from_fd(...);
if (IS_ERR(ruleset)) return PTR_ERR(ruleset);).

A local struct landlock_ruleset *domain assigned to restriction->domain on
success would also fold the explicit restriction->domain = NULL; reset away,
since restriction is already zeroed by the *restriction = (struct
landlock_restriction){}; above.

> diff --git a/security/landlock/cred.h b/security/landlock/cred.h
> index f287c56b5fd4b..1d5039b46ce7a 100644
> --- a/security/landlock/cred.h
> +++ b/security/landlock/cred.h
> @@ -20,6 +20,31 @@
>  #include "ruleset.h"
>  #include "setup.h"
>
> +/**
> + * struct landlock_restriction - Computed credential restriction
> + *
> + * The result of landlock_prepare_restriction(): the new state that
> + * enforcing a ruleset with a set of landlock_restrict_self(2) flags
> + * gives to a credential, decoupled from its application.  It is
> + * enforced with landlock_apply_restriction(), either right away
> + * (landlock_restrict_self(2)) or after a staging period (restriction
> + * of an execution).
> + */
> +struct landlock_restriction {
> +	/**
> +	 * @domain: New domain to enforce, owning a reference.  NULL if the
> +	 * restriction only carries a log configuration change.
> +	 */
> +	struct landlock_ruleset *domain;
> +#ifdef CONFIG_AUDIT
> +	/**
> +	 * @log_subdomains_off: New value of the credentials'
> +	 * @landlock_cred_security.log_subdomains_off.
> +	 */
> +	u8 log_subdomains_off : 1;
> +#endif /* CONFIG_AUDIT */
> +};

This isn't a bug, but would &landlock_cred_security.log_subdomains_off
work better here, so the rendered docs link to the other struct the way
ruleset.h does for &landlock_ruleset.root_inode?

The member description cross-references another struct's member with
@landlock_cred_security.log_subdomains_off. Per
Documentation/doc-guide/kernel-doc.rst, @parameter is for members of the
struct being documented (formatting only, no cross-referencing), while a
member of a different struct is written &struct_name.member to generate an
actual cross-reference.

cred.h is pulled into the rendered docs by
Documentation/security/landlock.rst (.. kernel-doc::
security/landlock/cred.h), so the reference renders as plain bold text
instead of a link to struct landlock_cred_security. The surrounding
subsystem already uses the & form for this, e.g.
security/landlock/ruleset.h:71 (Type of &landlock_ruleset.root_inode's node
keys).

> diff --git a/security/landlock/syscalls.c b/security/landlock/syscalls.c
> index 9af2407274b25..899601af7c4e1 100644
> --- a/security/landlock/syscalls.c
> +++ b/security/landlock/syscalls.c

This isn't a bug, but since this hunk drops the last BIT() and
hierarchy/LANDLOCK_LOG_* users in this file, could <linux/bitops.h> and
"domain.h" be dropped from syscalls.c too, mirroring the includes added to
cred.c?

Moving the domain merge and audit-log configuration into cred.c removes the
last users of two includes in syscalls.c, but both includes stay.
<linux/bitops.h> (earlier in the file) was needed only for the
BIT(new_dom->num_layers - 1) in the deleted domain_exec update, and
"domain.h" only for LANDLOCK_LOG_DISABLED and the
new_dom->hierarchy->log_* stores.

Grepping the post-patch file for every symbol either header declares
(BIT/GENMASK/hweight/fls/test_bit/set_bit/... and LANDLOCK_LOG_*,
landlock_hierarchy, landlock_details, landlock_init_hierarchy_log,
landlock_get_hierarchy, landlock_put_hierarchy, LANDLOCK_PATH_MAX_SIZE)
returns no hits.

cred.c correctly gains <linux/bits.h> and "domain.h" in the same commit,
so the dependency moved rather than disappeared. Note <linux/compiler_types.h>
is still needed (__always_inline at line 66) even though the
__maybe_unused user went away.

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/30599733854

  reply	other threads:[~2026-07-31 22:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31  2:20 [PATCH bpf-next 00/13] BPF interface for applying Landlock rulesets Justin Suess
2026-07-31  2:20 ` [PATCH bpf-next 01/13] lsm: Add LSM hook security_policy_kptr_from_fd Justin Suess
2026-07-31  2:20 ` [PATCH bpf-next 02/13] lsm: Add LSM hook security_policy_kptr_put Justin Suess
2026-07-31  2:20 ` [PATCH bpf-next 03/13] lsm: Add LSM hook security_bprm_enforce_policy_kptr Justin Suess
2026-07-31  2:20 ` [PATCH bpf-next 04/13] landlock: Expose the ruleset fd lookup to the rest of Landlock Justin Suess
2026-07-31  2:20 ` [PATCH bpf-next 05/13] landlock: Factor the credential restriction out of landlock_restrict_self() Justin Suess
2026-07-31 22:24   ` bot+bpf-ci [this message]
2026-07-31  2:20 ` [PATCH bpf-next 06/13] landlock: Implement the LSM policy kptr hooks Justin Suess
2026-07-31  2:20 ` [PATCH bpf-next 07/13] bpf: Add the LSM policy kfunc infrastructure Justin Suess
2026-07-31 22:24   ` bot+bpf-ci
2026-07-31  2:20 ` [PATCH bpf-next 08/13] bpf: Add the bpf_landlock_put_ruleset kfunc and ruleset destructor Justin Suess
2026-07-31  2:20 ` [PATCH bpf-next 09/13] bpf: Add the bpf_landlock_get_ruleset_from_fd kfunc Justin Suess
2026-07-31  2:20 ` [PATCH bpf-next 10/13] bpf: Add the bpf_landlock_restrict_binprm kfunc Justin Suess
2026-07-31  2:20 ` [PATCH bpf-next 11/13] selftests/bpf: Add tests for the Landlock policy kfuncs Justin Suess
2026-07-31  2:20 ` [PATCH bpf-next 12/13] landlock: Document the BPF kfunc interface Justin Suess
2026-07-31  2:20 ` [PATCH bpf-next 13/13] lsm: Document the LSM policy kptr hooks Justin Suess
2026-07-31 20:30 ` [PATCH bpf-next 00/13] BPF interface for applying Landlock rulesets Paul Moore
2026-07-31 21:15   ` Justin Suess
2026-07-31 21:28     ` Paul Moore
2026-08-05 21:37   ` Justin Suess
2026-08-05 21:49     ` Justin Suess
2026-08-05 22:51     ` Paul Moore
2026-08-06  0:32       ` Justin Suess
2026-08-07 20:36         ` Paul Moore
2026-08-07 22:00           ` Justin Suess
2026-08-09 19:18             ` Paul Moore
2026-08-09 19:45               ` Justin Suess

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=ea9b8de8b22eb98e115d87edf25dbf6793b5b00aadc9cb62ca09402e689545d8@mail.kernel.org \
    --to=bot+bpf-ci@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=clm@meta.com \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=gnoack@google.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=jack@suse.cz \
    --cc=kees@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=m@maowtm.org \
    --cc=martin.lau@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mic@digikod.net \
    --cc=paul@paul-moore.com \
    --cc=song@kernel.org \
    --cc=utilityemal77@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yonghong.song@linux.dev \
    /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