From: "Darrick J. Wong" <djwong@kernel.org>
To: cem@kernel.org
Cc: linux-fsdevel@vger.kernel.org, jack@suze.cz, hch@lst.de,
serge@hallyn.com, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] capabily: Add new capable_noaudit
Date: Fri, 26 Jun 2026 08:16:56 -0700 [thread overview]
Message-ID: <20260626151656.GT6078@frogsfrogsfrogs> (raw)
In-Reply-To: <20260626114533.102138-2-cem@kernel.org>
s/capabily/capability/ in the subject even if the typo actually makes it
easier to find the thread.
On Fri, Jun 26, 2026 at 01:45:20PM +0200, cem@kernel.org wrote:
> From: Carlos Maiolino <cem@kernel.org>
>
> In some situations (quota enforcement bypass in this case) we'd like to
> check for a specific capability without triggering spurious audit
> messages from security modules like selinux.
>
> Add a new helper so we don't need to use ns_capable_noaudit() directly.
>
> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
> ---
> include/linux/capability.h | 5 +++++
> kernel/capability.c | 17 +++++++++++++++++
> 2 files changed, 22 insertions(+)
>
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index 37db92b3d6f8..873416ba884c 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -145,6 +145,7 @@ extern bool has_capability_noaudit(struct task_struct *t, int cap);
> extern bool has_ns_capability_noaudit(struct task_struct *t,
> struct user_namespace *ns, int cap);
> extern bool capable(int cap);
> +extern bool capable_noaudit(int cap);
> extern bool ns_capable(struct user_namespace *ns, int cap);
> extern bool ns_capable_noaudit(struct user_namespace *ns, int cap);
> extern bool ns_capable_setid(struct user_namespace *ns, int cap);
> @@ -167,6 +168,10 @@ static inline bool capable(int cap)
> {
> return true;
> }
> +static inline bool capable_noaudit(int cap)
> +{
> + return true;
> +}
> static inline bool ns_capable(struct user_namespace *ns, int cap)
> {
> return true;
> diff --git a/kernel/capability.c b/kernel/capability.c
> index 829f49ae07b9..2c2d1e8300bd 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -416,6 +416,23 @@ bool capable(int cap)
> return ns_capable(&init_user_ns, cap);
> }
> EXPORT_SYMBOL(capable);
> +
> +/**
> + * capable_noaudit - Determine if the current task has a superior
> + * capability in effect (unaudited).
> + * @cap: The capability to be tested for
> + *
> + * This is the same as capable(), except it uses CAP_OPT_NOAUDIT as to prevent
> + * issuing spurious audit messages.
> + *
> + * This sets PF_SUPERPRIV on the task if the capability is available on the
> + * assumption that it's about to be used.
Can you mention that this checks the current process' effective
capabilities (as opposed to the real ones)? So that nobody else has to
suffer the confusion I pointed out in [1] which was the source of the
security bugs in the first place?
(I do like the wrapper though)
--D
[1] https://lore.kernel.org/linux-xfs/20260625160317.GY6078@frogsfrogsfrogs/
> + */
> +bool capable_noaudit(int cap)
> +{
> + return ns_capable_noaudit(&init_user_ns, cap);
> +}
> +EXPORT_SYMBOL(capable_noaudit);
> #endif /* CONFIG_MULTIUSER */
>
> /**
> --
> 2.54.0
>
>
next prev parent reply other threads:[~2026-06-26 15:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 11:45 [RFC PATCH 0/4] Introduce capable_noaudit cem
2026-06-26 11:45 ` [RFC PATCH 1/4] capabily: Add new capable_noaudit cem
2026-06-26 15:16 ` Darrick J. Wong [this message]
2026-06-26 15:31 ` Paul Moore
2026-06-26 17:46 ` Serge E. Hallyn
2026-06-26 11:45 ` [RFC PATCH 2/4] quota: Don't issue audit messages on quota enforcing cem
2026-06-26 15:18 ` Darrick J. Wong
2026-06-26 11:45 ` [RFC PATCH 3/4] xfs: replace ns_capable_noaudit() cem
2026-06-26 15:19 ` Darrick J. Wong
2026-06-26 11:45 ` [RFC PATCH 4/4] capability: unexport has_capability_noaudit cem
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=20260626151656.GT6078@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=cem@kernel.org \
--cc=hch@lst.de \
--cc=jack@suze.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=serge@hallyn.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