From: "Mickaël Salaün" <mic@digikod.net>
To: Tingmao Wang <m@maowtm.org>
Cc: "Günther Noack" <gnoack@google.com>,
"Daniel Burgener" <dburgener@linux.microsoft.com>,
"Jann Horn" <jannh@google.com>, "Jeff Xu" <jeffxu@google.com>,
"Kees Cook" <kees@kernel.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
"Matthieu Buffet" <matthieu@buffet.re>,
"Mikhail Ivanov" <ivanov.mikhail1@huawei-partners.com>,
"Ryan Sullivan" <rysulliv@redhat.com>,
"Shervin Oloumi" <enlightened@google.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
linux-security-module@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 2/5] landlock: Merge landlock_find_rule() into landlock_unmask_layers()
Date: Tue, 27 May 2025 16:53:22 +0200 [thread overview]
Message-ID: <20250527.un9ae3Ohlaih@digikod.net> (raw)
In-Reply-To: <ec7198c7-bed9-4a04-9ff0-da90ce729897@maowtm.org>
On Mon, May 26, 2025 at 07:38:07PM +0100, Tingmao Wang wrote:
> On 5/23/25 17:57, Mickaël Salaün wrote:
> > To be able to have useful traces, let's consolidate rule finding into
> > unmask checking. landlock_unmask_layers() now gets a landlock_rule_ref
> > instead of a rule pointer.
> >
> > This enables us to not deal with Landlock rule pointers outside of
> > ruleset.c, to avoid two calls, and to get all required information
> > available to landlock_unmask_layers().
> >
> > We could make struct landlock_rule private because it is now only used
> > in the ruleset.c file.
> >
> > Cc: Günther Noack <gnoack@google.com>
> > Signed-off-by: Mickaël Salaün <mic@digikod.net>
> > ---
> > security/landlock/fs.c | 144 ++++++++++++++++++++++--------------
> > security/landlock/net.c | 6 +-
> > security/landlock/ruleset.c | 12 ++-
> > security/landlock/ruleset.h | 9 +--
> > 4 files changed, 100 insertions(+), 71 deletions(-)
> >
> > diff --git a/security/landlock/fs.c b/security/landlock/fs.c
> > index f5087688190a..73a20a501c3c 100644
> > --- a/security/landlock/fs.c
> > +++ b/security/landlock/fs.c
> > @@ -356,30 +356,27 @@ int landlock_append_fs_rule(struct landlock_ruleset *const ruleset,
> > /* Access-control management */
> > /*
> > - * The lifetime of the returned rule is tied to @domain.
> > - *
> > - * Returns NULL if no rule is found or if @dentry is negative.
> > + * Returns true if an object is tied to @dentry, and updates @ref accordingly.
> > */
> > -static const struct landlock_rule *
> > -find_rule(const struct landlock_ruleset *const domain,
> > - const struct dentry *const dentry)
> > +static bool find_rule_ref(const struct dentry *const dentry,
> > + struct landlock_rule_ref *ref)
>
> I think a better name would be something like "get_rule_ref"? Since it's not
> really _finding_ anything (like doing a search in a rbtree).
Correct.
>
> (If you take the rename suggestion, then it would be "get_rule_target")
What about get_inode_ref()?
next prev parent reply other threads:[~2025-05-27 15:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-23 16:57 [RFC PATCH v1 0/5] Landlock tracepoints Mickaël Salaün
2025-05-23 16:57 ` [RFC PATCH v1 1/5] landlock: Rename landlock_id to landlock_rule_ref Mickaël Salaün
2025-05-26 18:38 ` Tingmao Wang
2025-05-27 14:53 ` Mickaël Salaün
2025-05-23 16:57 ` [RFC PATCH v1 2/5] landlock: Merge landlock_find_rule() into landlock_unmask_layers() Mickaël Salaün
2025-05-26 18:38 ` Tingmao Wang
2025-05-27 14:53 ` Mickaël Salaün [this message]
2025-05-23 16:57 ` [RFC PATCH v1 3/5] tracing: Add __print_untrusted_str() Mickaël Salaün
2025-05-23 18:22 ` Steven Rostedt
2025-05-26 17:46 ` Mickaël Salaün
2025-05-23 16:57 ` [RFC PATCH v1 4/5] landlock: Add landlock_add_rule_fs tracepoint Mickaël Salaün
2025-05-26 18:37 ` Tingmao Wang
2025-05-27 14:53 ` Mickaël Salaün
2025-05-23 16:57 ` [RFC PATCH v1 5/5] landlock: Add landlock_check_rule tracepoint Mickaël Salaün
2025-05-26 18:37 ` [RFC PATCH v1 0/5] Landlock tracepoints Tingmao Wang
2025-05-27 14:52 ` Mickaël Salaün
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=20250527.un9ae3Ohlaih@digikod.net \
--to=mic@digikod.net \
--cc=dburgener@linux.microsoft.com \
--cc=enlightened@google.com \
--cc=gnoack@google.com \
--cc=ivanov.mikhail1@huawei-partners.com \
--cc=jannh@google.com \
--cc=jeffxu@google.com \
--cc=kees@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=m@maowtm.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=matthieu@buffet.re \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=rysulliv@redhat.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;
as well as URLs for NNTP newsgroup(s).