* Re: [PATCH 0/6] selftests: fix multiple spelling errors across submodules
From: Sean Christopherson @ 2026-07-01 14:18 UTC (permalink / raw)
To: Wang Yan
Cc: Shuah Khan, Mickaël Salaün, Günther Noack,
linux-security-module, linux-kselftest, linux-kernel
In-Reply-To: <20260701123520.271580-1-wangyan01@kylinos.cn>
On Wed, Jul 01, 2026, Wang Yan wrote:
> This series fixes trivial spelling typos in comments across multiple
> selftests subdirectories. All changes are pure comment fixes, no
> functional or logical change to any test logic.
>
> Changes are split by subsystem for easier review and merging.
In the future, please send individual patches. Splitting the patches is nice,
but then bundling them in a single series that affects different maintainer
domains reintroduces the friction you're trying to avoid, especially since most
of us only got the one patch. E.g. I only received patch 4/6, which left me
wondering "what's in the other 5 patches?".
> Wang Yan (6):
> selftests/arm64: fix spelling errors in comments
> selftests/filesystems: fix spelling error in statmount test comment
> selftests/ftrace: fix spelling error in poll test comment
> selftests/kvm/x86: fix spelling error in xapic_ipi_test comment
> selftests/landlock: fix spelling error in fs_test comment
> selftests/powerpc/tm: fix spelling errors in comments
>
> tools/testing/selftests/arm64/gcs/libc-gcs.c | 2 +-
> tools/testing/selftests/arm64/pauth/pac.c | 2 +-
> tools/testing/selftests/filesystems/statmount/statmount_test.c | 2 +-
> tools/testing/selftests/ftrace/poll.c | 2 +-
> tools/testing/selftests/kvm/x86/xapic_ipi_test.c | 2 +-
> tools/testing/selftests/landlock/fs_test.c | 2 +-
> tools/testing/selftests/powerpc/tm/tm-signal-msr-resv.c | 2 +-
> tools/testing/selftests/powerpc/tm/tm-signal-stack.c | 2 +-
> tools/testing/selftests/powerpc/tm/tm-tar.c | 2 +-
> 9 files changed, 9 insertions(+), 9 deletions(-)
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v4 bpf-next 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Paul Moore @ 2026-07-01 15:09 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Windsor, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Jiri Olsa,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Matt Bobrowski,
James Morris, Serge E . Hallyn, Casey Schaufler, Stephen Smalley,
Ondrej Mosnacek, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Alexander Viro, Christian Brauner, Jan Kara,
Shuah Khan, bpf, linux-security-module, linux-fsdevel,
linux-integrity, selinux, linux-kselftest, linux-kernel
In-Reply-To: <CAHC9VhT37f5TwgksE_i0Yttpy3i7niBr6QrNVVmpwe_eGX428g@mail.gmail.com>
On Wed, Jul 1, 2026 at 8:55 AM Paul Moore <paul@paul-moore.com> wrote:
> On Wed, Jul 1, 2026 at 2:09 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> > On Tue Jun 30, 2026 at 12:20 PM PDT, Paul Moore wrote:
> > >> +__bpf_kfunc int bpf_init_inode_xattr(struct lsm_xattrs *xattrs,
> > >> + const char *name__str,
> > >> + const struct bpf_dynptr *value_p)
> > >> +{
> > >> + struct bpf_dynptr_kern *value_ptr = (struct bpf_dynptr_kern *)value_p;
> > >> + size_t name_len;
> > >> + void *xattr_value;
> > >> + struct xattr *xattr;
> > >> + const void *value;
> > >> + u32 value_len;
> > >> +
> > >> + if (!xattrs || !xattrs->xattrs || !name__str)
> > >> + return -EINVAL;
> > >> + if (bpf_xattrs_used(xattrs) >= BPF_LSM_INODE_INIT_XATTRS)
> > >> + return -ENOSPC;
> > >> +
> > >> + name_len = strlen(name__str);
> > >> + if (name_len == 0 || name_len > XATTR_NAME_MAX)
> > >> + return -EINVAL;
> > >> + if (strncmp(name__str, XATTR_BPF_LSM_SUFFIX,
> > >> + sizeof(XATTR_BPF_LSM_SUFFIX) - 1))
> > >> + return -EPERM;
> > >> +
> > >> + value_len = __bpf_dynptr_size(value_ptr);
> > >> + if (value_len == 0 || value_len > XATTR_SIZE_MAX)
> > >> + return -EINVAL;
> > >> +
> > >> + value = __bpf_dynptr_data(value_ptr, value_len);
> > >> + if (!value)
> > >> + return -EINVAL;
> > >> +
> > >> + /* Combine xattr value + name into one allocation. */
> > >> + xattr_value = kmalloc(value_len + name_len + 1, GFP_NOFS);
> > >> + if (!xattr_value)
> > >> + return -ENOMEM;
> > >> +
> > >> + memcpy(xattr_value, value, value_len);
> > >> + memcpy(xattr_value + value_len, name__str, name_len);
> > >> + ((char *)xattr_value)[value_len + name_len] = '\0';
> > >> +
> > >> + xattr = lsm_get_xattr_slot(xattrs);
> > >> + if (!xattr) {
> > >> + kfree(xattr_value);
> > >> + return -ENOSPC;
> > >> + }
> > >> +
> > >> + xattr->value = xattr_value;
> > >> + xattr->name = (const char *)xattr_value + value_len;
> > >> + xattr->value_len = value_len;
> > >> +
> > >> + return 0;
> > >> +}
> > >
> > > This is not a generic VFS function, it is a LSM specific function, it
> > > belongs under security/, please move the code as discussed previously.
> >
> > Paul,
> > Not quite. It's all about xattrs.
> > Having "struct lsm_xattrs" in the arguments doesn't make it lsm related.
> > You needs to study existing kfuncs and tracepoints.
> > A bunch of them have "*lsm*" in the arguments.
>
> Alexei,
>
> I'm sorry you don't understand the basics of the LSM concept, but
> please look at evm_inode_init_security(), xattr_dupval(), and
> selinux_inode_init_security() for some background. There should not
> be any usage of lsm_get_xattr_slot() or BPF_LSM_INODE_INIT_XATTRS
> outside of security/; you argued a similar idea to justify your NACK
> of Hornet, I'm simply applying the same logic here. We also have the
> very recent security issue caused by the BPF subsystem which failed to
> acknowledge that the admin disabled the BPF LSM and then walked all
> over kernel memory when it shouldn't. Moving LSM internals outside of
> the LSM creates an environment where flaws like this can go
> undetected.
>
> As I said previously, if you absolutely insist on the kfunc being in
> the VFS kfunc file, the LSM specific bits need to be abstracted out
> into an LSM function.
>
> kfunc bpf_init_inode_xattr(...)
> {
> /* sanity check params */
> if (!xattrs ...)
> return -EINVAL;
>
> /* get value/len from bpf dynptr */
>
> /* hook will check for LSM specific xattr count/limits, allocate,
> copy value*/
> rc = security_lsmxattr_add(xattrs, LSM_ID_BPF, value, value_len);
> if (rc)
> return rc;
> }
>
> David, if you like I can provide you a patch that implements the
> security_lsmxattr_add() hook above if you aren't comfortable writing
> that, but if you want to give it a shot that's all the better :)
One other thing - as this patchset is primarily LSM related, it needs
to be merged via the LSM tree. If Alexei can't tolerate the LSM tree
merging a minor BPF patch he can either choose to pull from an LSM
tree topic branch or we can merge the LSM infrastructure bits now and
he can merge the BPF changes when the LSM bits hit Linus' tree.
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Justin Suess @ 2026-07-01 18:29 UTC (permalink / raw)
To: Paul Moore
Cc: Mickaël Salaün, ast, daniel, andrii, kpsingh, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, john.fastabend, sdf, skhan, bpf,
linux-security-module, linux-kernel, linux-fsdevel,
Frederick Lawler
In-Reply-To: <CAHC9VhSjRcMr9+5dMkep_TPKduYdob-bZ73FLfXd_o2xiWwOSg@mail.gmail.com>
On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > from accessing unstable internal Landlock fields.
> > >
> > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > function as examples.
> >
> > I would raise bpf_ima_file_hash, bpf_ima_inode_hash, as examples of
> > clear precedence for this. (BPF calling into specific LSM)
>
> The BPF IMA helpers were merged back in the v5.18 timeframe when IMA
> was still standalone, it wasn't until v6.9 that IMA and EVM became
> proper LSMs.
>
> > Kfuncs are explicitly marked as not being an ABI, and are more
> > flexible for later changes / deprecation etc. [1]
>
> The issue isn't so much the kfunc itself, it is what the kfunc
> *calls*. From what I saw in the proposed patch, the kfunc calls
> directly into Landlock instead of passing through the LSM framework,
> e.g. a function wrapper in security/security.c.
>
> > LSM framework API can mean a lot of things. I assume you are meaning
> > like a pseudo-filesystem mounted interface that controls LSM?
> > Correct me if I'm wrong.
>
> My apologies, I should have been more clear. When I speak about the
> "LSM framework", I'm talking about the abstraction layer that provides
> the interface that the kernel and userspace uses to talk to individual
> LSMs. The LSM framework is analogous to the VFS layer/framework in
> that it provides a single API for a variety of underlying subsystems.
> While not 100% correct, you can think of it the LSM framework as being
> the functions/hooks defined in security/security.c.
>
> Does that help?
>
That does. security/security.c seems like a good place to enumerate the enabled
LSMs and to check to make sure that Landlock is actually enabled both in the kernel
build and that the Landlock LSM is up and running.
The above patch only checked if Landlock was compiled, when it should
actually be checking if Landlock is actively enabled.
So I will probably make a shim for it there that gates calls to
Landlock.
> --
> paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Paul Moore @ 2026-07-01 18:33 UTC (permalink / raw)
To: Justin Suess
Cc: Mickaël Salaün, ast, daniel, andrii, kpsingh, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, john.fastabend, sdf, skhan, bpf,
linux-security-module, linux-kernel, linux-fsdevel,
Frederick Lawler
In-Reply-To: <akVbLGYyafZq_93v@zenbox>
On Wed, Jul 1, 2026 at 2:29 PM Justin Suess <utilityemal77@gmail.com> wrote:
> On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > from accessing unstable internal Landlock fields.
> > > >
> > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > function as examples.
> > >
> > > I would raise bpf_ima_file_hash, bpf_ima_inode_hash, as examples of
> > > clear precedence for this. (BPF calling into specific LSM)
> >
> > The BPF IMA helpers were merged back in the v5.18 timeframe when IMA
> > was still standalone, it wasn't until v6.9 that IMA and EVM became
> > proper LSMs.
> >
> > > Kfuncs are explicitly marked as not being an ABI, and are more
> > > flexible for later changes / deprecation etc. [1]
> >
> > The issue isn't so much the kfunc itself, it is what the kfunc
> > *calls*. From what I saw in the proposed patch, the kfunc calls
> > directly into Landlock instead of passing through the LSM framework,
> > e.g. a function wrapper in security/security.c.
> >
> > > LSM framework API can mean a lot of things. I assume you are meaning
> > > like a pseudo-filesystem mounted interface that controls LSM?
> > > Correct me if I'm wrong.
> >
> > My apologies, I should have been more clear. When I speak about the
> > "LSM framework", I'm talking about the abstraction layer that provides
> > the interface that the kernel and userspace uses to talk to individual
> > LSMs. The LSM framework is analogous to the VFS layer/framework in
> > that it provides a single API for a variety of underlying subsystems.
> > While not 100% correct, you can think of it the LSM framework as being
> > the functions/hooks defined in security/security.c.
> >
> > Does that help?
>
> That does. security/security.c seems like a good place to enumerate the enabled
> LSMs and to check to make sure that Landlock is actually enabled both in the kernel
> build and that the Landlock LSM is up and running.
Yep.
> The above patch only checked if Landlock was compiled, when it should
> actually be checking if Landlock is actively enabled.
>
> So I will probably make a shim for it there that gates calls to
> Landlock.
Please keep in mind that the LSM framework API needs to be reasonably
generic. We've got some general guidance on adding new LSM hooks at
the link below:
https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-hooks
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Mickaël Salaün @ 2026-07-01 18:34 UTC (permalink / raw)
To: Paul Moore, ast, daniel, kpsingh, john.fastabend
Cc: Justin Suess, andrii, viro, brauner, kees, gnoack, jack, jmorris,
serge, song, yonghong.song, martin.lau, m, eddyz87, sdf, skhan,
bpf, linux-security-module, linux-kernel, linux-fsdevel,
Frederick Lawler
In-Reply-To: <CAHC9VhSjRcMr9+5dMkep_TPKduYdob-bZ73FLfXd_o2xiWwOSg@mail.gmail.com>
On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > from accessing unstable internal Landlock fields.
> > >
> > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > function as examples.
This patch series is not about the LSM framework, only about Landlock
and its specific model and use case. Landlock using some of the LSM API
is not relevant here.
> >
> > I would raise bpf_ima_file_hash, bpf_ima_inode_hash, as examples of
> > clear precedence for this. (BPF calling into specific LSM)
>
> The BPF IMA helpers were merged back in the v5.18 timeframe when IMA
> was still standalone, it wasn't until v6.9 that IMA and EVM became
> proper LSMs.
>
> > Kfuncs are explicitly marked as not being an ABI, and are more
> > flexible for later changes / deprecation etc. [1]
>
> The issue isn't so much the kfunc itself, it is what the kfunc
> *calls*. From what I saw in the proposed patch, the kfunc calls
> directly into Landlock instead of passing through the LSM framework,
> e.g. a function wrapper in security/security.c.
Yes, and I'm OK for this kfunc to call directly into a new public
Landlock function. There is no need to create a new class of LSM
wrapper.
LSM hooks make sense because they are designed for a specific subsystem
(the caller) and their goal is to return an access decision or to keep
up-to-date related states, which means that their API is designed for
the caller, with its own types and specificities, not the other way
around. This case is different, the kfunc is strongly typed and tied to
the Landlock (subsystem) semantic with an API defined by and for
Landlock. I don't think a multiplexer would be a good idea.
However, I agree with your layering concern, and it would make more
sense to move the Landlock-related kfuncs to security/landlock/bpf.c,
which is also the idiomatic way for subsystems to own their API.
Alexei, KP, what do you think?
>
> > LSM framework API can mean a lot of things. I assume you are meaning
> > like a pseudo-filesystem mounted interface that controls LSM?
> > Correct me if I'm wrong.
>
> My apologies, I should have been more clear. When I speak about the
> "LSM framework", I'm talking about the abstraction layer that provides
> the interface that the kernel and userspace uses to talk to individual
> LSMs. The LSM framework is analogous to the VFS layer/framework in
> that it provides a single API for a variety of underlying subsystems.
> While not 100% correct, you can think of it the LSM framework as being
> the functions/hooks defined in security/security.c.
This abstraction layer is useful and make sense for access control hooks
but it is not needed in this case, and it would only make the kfunc
interface more complex for no reason. If any other kernel subsystem
wants to add a kfunc, I think it should be reviewed with its purpose in
mind and a well defined use case.
>
> Does that help?
I think Justin is right, and with some minor changes this kfunc should
be good.
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Paul Moore @ 2026-07-01 18:38 UTC (permalink / raw)
To: Mickaël Salaün
Cc: ast, daniel, kpsingh, john.fastabend, Justin Suess, andrii, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <20260701.jei4Paej3zen@digikod.net>
On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > from accessing unstable internal Landlock fields.
> > > >
> > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > function as examples.
>
> This patch series is not about the LSM framework, only about Landlock
> and its specific model and use case. Landlock using some of the LSM API
> is not relevant here.
Based on a quick look the patchset enables BPF programs to call
directly into Landlock. For the same reason we discourage other parts
of the kernel to call directly into individual LSMs, we want to
discourage BPF programs from calling directly into individual LSMs.
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Mickaël Salaün @ 2026-07-01 19:49 UTC (permalink / raw)
To: Paul Moore
Cc: ast, daniel, kpsingh, john.fastabend, Justin Suess, andrii, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <CAHC9VhRzZVUz8icZ2RD9OVvscJdZW3ivPERJLEkNi5poBeguxw@mail.gmail.com>
On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > > from accessing unstable internal Landlock fields.
> > > > >
> > > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > > function as examples.
> >
> > This patch series is not about the LSM framework, only about Landlock
> > and its specific model and use case. Landlock using some of the LSM API
> > is not relevant here.
>
> Based on a quick look the patchset enables BPF programs to call
> directly into Landlock. For the same reason we discourage other parts
> of the kernel to call directly into individual LSMs, we want to
> discourage BPF programs from calling directly into individual LSMs.
We're OK for a dedicated kfunc to call directly into Landlock (with a
tailored interface). Landlock is designed around its syscall interfaces
(well documented, tailored, tested), and this would be a new user of
almost the same UAPI.
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Justin Suess @ 2026-07-01 19:55 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Paul Moore, ast, daniel, kpsingh, john.fastabend, andrii, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <20260701.oTeikequi3ee@digikod.net>
On Wed, Jul 01, 2026 at 09:49:07PM +0200, Mickaël Salaün wrote:
> On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> > On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> > > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > > > from accessing unstable internal Landlock fields.
> > > > > >
> > > > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > > > function as examples.
> > >
> > > This patch series is not about the LSM framework, only about Landlock
> > > and its specific model and use case. Landlock using some of the LSM API
> > > is not relevant here.
> >
> > Based on a quick look the patchset enables BPF programs to call
> > directly into Landlock. For the same reason we discourage other parts
> > of the kernel to call directly into individual LSMs, we want to
> > discourage BPF programs from calling directly into individual LSMs.
>
> We're OK for a dedicated kfunc to call directly into Landlock (with a
> tailored interface). Landlock is designed around its syscall interfaces
> (well documented, tailored, tested), and this would be a new user of
> almost the same UAPI.
Paul, Mickaël,
I think there's a cleaner way to resolve this.
First, walking back my earlier email: I was wrong saying that we need to call
into security/security.c to check whether Landlock is enabled. Landlock's
init only runs when it's in the active lsm= list, so I can just test
landlock_initialized directly. There's no per-invocation reason to route
through the LSM framework for that.
Rather than routing each kfunc *invocation* through a security/security.c
wrapper, I think the right place for the framework to be involved is
*registration*: have the LSM framework own registration of an LSM's
kfunc sets, e.g.
int security_register_lsm_kfunc_set(u64 lsm_id, enum bpf_prog_type type,
const struct btf_kfunc_id_set *kset);
Each LSM calls this once to register its sets. Because registration goes
through the framework, the framework gets to decide whether to actually
register them so you could, for example, run an LSM while explicitly
opting its BPF kfuncs out. (something that should be done at the LSM
framework level).
This gives the framework control over kfunc enablement without an
pointless indirection on every call, and without making the kfunc
interface any more complex.
So this satisfies both sides of this argument:
Mickaël, this fits your suggestion to move them to security/landlock/bpf.c
and call directly into a Landlock function without needless abstraction.
We just register the landlock kfunc set with
security_register_lsm_kfunc_set, and that's it.
Paul, this way the LSM framework would have visibility into the
registration and enablement of the kfuncs that concern it.
Does this strike a reasonable balance?
Justin
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Paul Moore @ 2026-07-01 19:56 UTC (permalink / raw)
To: Mickaël Salaün
Cc: ast, daniel, kpsingh, john.fastabend, Justin Suess, andrii, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <20260701.oTeikequi3ee@digikod.net>
On Wed, Jul 1, 2026 at 3:49 PM Mickaël Salaün <mic@digikod.net> wrote:
> On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> > On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> > > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > > > from accessing unstable internal Landlock fields.
> > > > > >
> > > > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > > > function as examples.
> > >
> > > This patch series is not about the LSM framework, only about Landlock
> > > and its specific model and use case. Landlock using some of the LSM API
> > > is not relevant here.
> >
> > Based on a quick look the patchset enables BPF programs to call
> > directly into Landlock. For the same reason we discourage other parts
> > of the kernel to call directly into individual LSMs, we want to
> > discourage BPF programs from calling directly into individual LSMs.
>
> We're OK for a dedicated kfunc to call directly into Landlock (with a
> tailored interface). Landlock is designed around its syscall interfaces
> (well documented, tailored, tested), and this would be a new user of
> almost the same UAPI.
Larger issues exist beyond the suitability of Landlock's API; in fact
Landlock's API isn't really the issue as far as I'm concerned. The
issue is that we don't want the kernel, whether via C code or BPF
code, calling directly into individual LSMs. We don't even support
LSM A calling directly into LSM B. Any caller making a call into an
LSM really needs to do so through an LSM hook.
I'm not opposed to allowing BPF code to call into Landlock, it just
needs to do so through an LSM hook like everything else to date.
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Paul Moore @ 2026-07-01 20:02 UTC (permalink / raw)
To: Justin Suess
Cc: Mickaël Salaün, ast, daniel, kpsingh, john.fastabend,
andrii, viro, brauner, kees, gnoack, jack, jmorris, serge, song,
yonghong.song, martin.lau, m, eddyz87, sdf, skhan, bpf,
linux-security-module, linux-kernel, linux-fsdevel,
Frederick Lawler
In-Reply-To: <akVvkA3kmlv_POsF@zenbox>
On Wed, Jul 1, 2026 at 3:55 PM Justin Suess <utilityemal77@gmail.com> wrote:
> On Wed, Jul 01, 2026 at 09:49:07PM +0200, Mickaël Salaün wrote:
> > On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> > > On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> > > > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > > > > from accessing unstable internal Landlock fields.
> > > > > > >
> > > > > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > > > > function as examples.
> > > >
> > > > This patch series is not about the LSM framework, only about Landlock
> > > > and its specific model and use case. Landlock using some of the LSM API
> > > > is not relevant here.
> > >
> > > Based on a quick look the patchset enables BPF programs to call
> > > directly into Landlock. For the same reason we discourage other parts
> > > of the kernel to call directly into individual LSMs, we want to
> > > discourage BPF programs from calling directly into individual LSMs.
> >
> > We're OK for a dedicated kfunc to call directly into Landlock (with a
> > tailored interface). Landlock is designed around its syscall interfaces
> > (well documented, tailored, tested), and this would be a new user of
> > almost the same UAPI.
>
> Paul, Mickaël,
>
> I think there's a cleaner way to resolve this.
>
> First, walking back my earlier email: I was wrong saying that we need to call
> into security/security.c to check whether Landlock is enabled. Landlock's
> init only runs when it's in the active lsm= list, so I can just test
> landlock_initialized directly. There's no per-invocation reason to route
> through the LSM framework for that.
The landlock_initialized flag is not really a LSM framework API, that
is still Landlock specific which is something we try hard to avoid.
> Rather than routing each kfunc *invocation* through a security/security.c
> wrapper, I think the right place for the framework to be involved is
> *registration*: have the LSM framework own registration of an LSM's
> kfunc sets, e.g.
>
> int security_register_lsm_kfunc_set(u64 lsm_id, enum bpf_prog_type type,
> const struct btf_kfunc_id_set *kset);
That implies a set of LSM kfunc APIs which Alexei has been deadset
against (see other ongoing threads).
> Each LSM calls this once to register its sets. Because registration goes
> through the framework, the framework gets to decide whether to actually
> register them so you could, for example, run an LSM while explicitly
> opting its BPF kfuncs out. (something that should be done at the LSM
> framework level).
I'm not opposed to the LSM supporting a set of kfuncs, see my comments
in other threads, but we should treat these kfuncs just as we treat
other LSM hooks today because that is what they are: LSM hooks that
happened to be called from within a BPF program.
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Mickaël Salaün @ 2026-07-01 21:28 UTC (permalink / raw)
To: Paul Moore
Cc: Justin Suess, ast, daniel, kpsingh, john.fastabend, andrii, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <CAHC9VhTQtHPFGqu58EaFqMobV3LCcTsdzYfxy568P8mU769TMg@mail.gmail.com>
On Wed, Jul 01, 2026 at 04:02:36PM -0400, Paul Moore wrote:
> On Wed, Jul 1, 2026 at 3:55 PM Justin Suess <utilityemal77@gmail.com> wrote:
> > On Wed, Jul 01, 2026 at 09:49:07PM +0200, Mickaël Salaün wrote:
> > > On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> > > > On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > > > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > > > > > from accessing unstable internal Landlock fields.
> > > > > > > >
> > > > > > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > > > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > > > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > > > > > function as examples.
> > > > >
> > > > > This patch series is not about the LSM framework, only about Landlock
> > > > > and its specific model and use case. Landlock using some of the LSM API
> > > > > is not relevant here.
> > > >
> > > > Based on a quick look the patchset enables BPF programs to call
> > > > directly into Landlock. For the same reason we discourage other parts
> > > > of the kernel to call directly into individual LSMs, we want to
> > > > discourage BPF programs from calling directly into individual LSMs.
> > >
> > > We're OK for a dedicated kfunc to call directly into Landlock (with a
> > > tailored interface). Landlock is designed around its syscall interfaces
> > > (well documented, tailored, tested), and this would be a new user of
> > > almost the same UAPI.
> >
> > Paul, Mickaël,
> >
> > I think there's a cleaner way to resolve this.
> >
> > First, walking back my earlier email: I was wrong saying that we need to call
> > into security/security.c to check whether Landlock is enabled. Landlock's
> > init only runs when it's in the active lsm= list, so I can just test
> > landlock_initialized directly. There's no per-invocation reason to route
> > through the LSM framework for that.
>
> The landlock_initialized flag is not really a LSM framework API, that
> is still Landlock specific which is something we try hard to avoid.
>
> > Rather than routing each kfunc *invocation* through a security/security.c
> > wrapper, I think the right place for the framework to be involved is
> > *registration*: have the LSM framework own registration of an LSM's
> > kfunc sets, e.g.
> >
> > int security_register_lsm_kfunc_set(u64 lsm_id, enum bpf_prog_type type,
> > const struct btf_kfunc_id_set *kset);
>
> That implies a set of LSM kfunc APIs which Alexei has been deadset
> against (see other ongoing threads).
>
> > Each LSM calls this once to register its sets. Because registration goes
> > through the framework, the framework gets to decide whether to actually
> > register them so you could, for example, run an LSM while explicitly
> > opting its BPF kfuncs out. (something that should be done at the LSM
> > framework level).
>
> I'm not opposed to the LSM supporting a set of kfuncs, see my comments
> in other threads, but we should treat these kfuncs just as we treat
> other LSM hooks today because that is what they are: LSM hooks that
> happened to be called from within a BPF program.
What an LSM hook is or should be is the crux of the misunderstanding. I
explained my point of view here:
https://lore.kernel.org/all/20260701.jei4Paej3zen@digikod.net/
LSM hooks make sense because they are designed for a specific subsystem
(the caller) and their goal is to return an access decision or to keep
up-to-date related states, which means that their API is designed for
the caller, with its own types and specificities, not the other way
around. This case is different, the kfunc is strongly typed and tied to
the Landlock (subsystem) semantic with an API defined by and for
Landlock. I don't think a multiplexer would be a good idea.
I'd try to explain better: in a nutshell, an LSM hook exposes a subset
of the context of the caller, for any access control system to be able
to make a decision. It makes sense to have such dispatcher because the
callees must adapt to the caller's context, and then the API is tailored
to the caller, so even with several consumers, the API would ultimately
be the same. In the case of this kfunc, the callee is one specific
subsystem that happens to be Landlock. The caller asks a specific
subsystem to do something specific to this subsystem, not to ask all
potential access control systems to give a generic verdict to grant an
access or not. For this kfunc, the caller passes arguments which are
specific to the callee subsystem (e.g. a Landlock ruleset), not the
other way around. Every LSM has its own configuration, and it doesn't
make sense to somehow wrap these configurations with a common layer/API.
That's the same thing here.
Why not start with something simple that fits a use case now? If and
when another LSM will need a kfunc, then we'll have something concrete
to talk about.
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Casey Schaufler @ 2026-07-01 21:41 UTC (permalink / raw)
To: Paul Moore, Justin Suess
Cc: Mickaël Salaün, ast, daniel, kpsingh, john.fastabend,
andrii, viro, brauner, kees, gnoack, jack, jmorris, serge, song,
yonghong.song, martin.lau, m, eddyz87, sdf, skhan, bpf,
linux-security-module, linux-kernel, linux-fsdevel,
Frederick Lawler, Casey Schaufler
In-Reply-To: <CAHC9VhTQtHPFGqu58EaFqMobV3LCcTsdzYfxy568P8mU769TMg@mail.gmail.com>
On 7/1/2026 1:02 PM, Paul Moore wrote:
> ...
>
>> Each LSM calls this once to register its sets. Because registration goes
>> through the framework, the framework gets to decide whether to actually
>> register them so you could, for example, run an LSM while explicitly
>> opting its BPF kfuncs out. (something that should be done at the LSM
>> framework level).
> I'm not opposed to the LSM supporting a set of kfuncs, see my comments
> in other threads, but we should treat these kfuncs just as we treat
> other LSM hooks today because that is what they are: LSM hooks that
> happened to be called from within a BPF program.
As someone who has been working to get the SELinux specific assumptions
out of the LSM framework for the past 15 years the notion of adding
Landlock specific interfaces makes me want to cry. Is it really that
difficult to understand that 5 or 10 years from now something is going
to come along that makes any LSM specific interface a nightmare? What
if there's an LSM that does what Landlock does, but does it better?
What if the Landlock sponsors decide to quit funding it? Or the maintainers
get bored?
I agree with Paul completely. Make the hooks available to any and all
LSMs, or don't make them at all.
^ permalink raw reply
* [PATCH v2 1/2] landlock: fix TCP Fast Open connection bypass
From: Matthieu Buffet @ 2026-07-01 21:46 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Bryam Vargas, Günther Noack, linux-security-module,
Mikhail Ivanov, Paul Moore, Eric Dumazet, Neal Cardwell,
linux-kernel, netdev, Matthieu Buffet
In-Reply-To: <c21cf4f3-6c21-4170-b578-13c1bfd48b87@buffet.re>
The documentation of the socket_connect() LSM hook states that it
controls connecting a socket to a remote address. It has not been the
case since the addition of TCP Fast Open (RFC 7413) support, which allows
opening a TCP connection (thus, setting a socket's destination address)
via the MSG_FASTOPEN flag passed to sendto()/sendmsg()/sendmmsg(). The
problem then got duplicated into MPTCP.
Landlock did not take it into account when its TCP support was added,
leaving a bypass of TCP connect policy.
Ideally a call to the LSM hook would be added in the fastopen code path,
in order to fix this generically. But connect() hooks are designed to run
with the socket locked, unlike sendmsg() hooks.
Closes: https://github.com/landlock-lsm/linux/issues/41
Fixes: fff69fb03dde ("landlock: Support network rules with TCP bind and connect")
Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
---
security/landlock/net.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/security/landlock/net.c b/security/landlock/net.c
index cbff59ec3aba..46c17116fcf4 100644
--- a/security/landlock/net.c
+++ b/security/landlock/net.c
@@ -351,6 +351,14 @@ static int hook_socket_sendmsg(struct socket *const sock,
access_mask_t access_request;
int ret = 0;
+ if ((msg->msg_flags & MSG_FASTOPEN) && address && sk_is_tcp(sock->sk)) {
+ ret = current_check_access_socket(
+ sock, address, addrlen, LANDLOCK_ACCESS_NET_CONNECT_TCP,
+ true);
+ if (ret != 0)
+ return ret;
+ }
+
if (sk_is_udp(sock->sk))
access_request = LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP;
else
--
2.47.3
^ permalink raw reply related
* [PATCH v2 2/2] selftests/landlock: Add test for TCP fast open
From: Matthieu Buffet @ 2026-07-01 21:46 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Bryam Vargas, Günther Noack, linux-security-module,
Mikhail Ivanov, Paul Moore, Eric Dumazet, Neal Cardwell,
linux-kernel, netdev, Matthieu Buffet
In-Reply-To: <20260701214628.33319-1-matthieu@buffet.re>
Enforce that TCP Fast Open is controlled by
LANDLOCK_ACCESS_NET_CONNECT_TCP. Semantics of connect() and
sendmsg(MSG_FASTOPEN) should be identical from Landlock's perspective.
Also enforce error code consistency, since UDP sockets ignore
the MSG_FASTOPEN flag while Unix sockets reject it.
Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
---
tools/testing/selftests/landlock/net_test.c | 94 +++++++++++++++++++++
1 file changed, 94 insertions(+)
diff --git a/tools/testing/selftests/landlock/net_test.c b/tools/testing/selftests/landlock/net_test.c
index 2ed1f76b7a8b..2e4dc5025b04 100644
--- a/tools/testing/selftests/landlock/net_test.c
+++ b/tools/testing/selftests/landlock/net_test.c
@@ -1281,6 +1281,100 @@ TEST_F(protocol, connect_unspec)
EXPECT_EQ(0, close(bind_fd));
}
+TEST_F(protocol, tcp_fastopen)
+{
+ const bool restricted = variant->sandbox == TCP_SANDBOX &&
+ variant->prot.type == SOCK_STREAM &&
+ (variant->prot.protocol == IPPROTO_TCP || variant->prot.protocol == IPPROTO_IP) &&
+ (variant->prot.domain == AF_INET || variant->prot.domain == AF_INET6);
+ const struct landlock_ruleset_attr ruleset_attr = {
+ .handled_access_net = LANDLOCK_ACCESS_NET_CONNECT_TCP,
+ };
+ int bind_fd, client_fd, status;
+ char buf;
+ pid_t child;
+
+ bind_fd = socket_variant(&self->srv0);
+ ASSERT_LE(0, bind_fd);
+ EXPECT_EQ(0, bind_variant(bind_fd, &self->srv0));
+ if (self->srv0.protocol.type == SOCK_STREAM)
+ EXPECT_EQ(0, listen(bind_fd, backlog));
+
+ child = fork();
+ ASSERT_LE(0, child);
+ if (child == 0) {
+ int connect_fd, ret;
+
+ /* Closes listening socket for the child. */
+ EXPECT_EQ(0, close(bind_fd));
+
+ connect_fd = socket_variant(&self->srv0);
+ ASSERT_LE(0, connect_fd);
+
+ if (variant->sandbox == TCP_SANDBOX) {
+ const int ruleset_fd = landlock_create_ruleset(
+ &ruleset_attr, sizeof(ruleset_attr), 0);
+ ASSERT_LE(0, ruleset_fd);
+
+ enforce_ruleset(_metadata, ruleset_fd);
+ EXPECT_EQ(0, close(ruleset_fd));
+ }
+
+ /* Fast Open with no address. */
+ ret = sendto_variant(connect_fd, NULL, NULL, 0, MSG_FASTOPEN);
+ if (self->srv0.protocol.domain == AF_UNIX) {
+ EXPECT_EQ(-ENOTCONN, ret);
+ } else if (self->srv0.protocol.type == SOCK_DGRAM) {
+ EXPECT_EQ(-EDESTADDRREQ, ret);
+ } else {
+ EXPECT_EQ(-EINVAL, ret);
+ }
+
+ /* Fast Open to a denied address. */
+ ret = sendto_variant(connect_fd, &self->srv0, "A", 1, MSG_FASTOPEN);
+ if (restricted) {
+ EXPECT_EQ(-EACCES, ret);
+ } else if (self->srv0.protocol.domain == AF_UNIX &&
+ self->srv0.protocol.type == SOCK_STREAM) {
+ EXPECT_EQ(-EOPNOTSUPP, ret);
+ } else {
+ EXPECT_EQ(0, ret);
+ }
+
+ EXPECT_EQ(0, close(connect_fd));
+ _exit(_metadata->exit_code);
+ return;
+ }
+
+ client_fd = bind_fd;
+ if (!restricted && self->srv0.protocol.type == SOCK_STREAM &&
+ self->srv0.protocol.domain != AF_UNIX) {
+ client_fd = accept(bind_fd, NULL, 0);
+ ASSERT_LE(0, client_fd);
+ }
+
+ if (restricted) {
+ EXPECT_EQ(-1, read(client_fd, &buf, 1));
+ EXPECT_EQ(ENOTCONN, errno);
+ } else if (self->srv0.protocol.domain == AF_UNIX &&
+ self->srv0.protocol.type == SOCK_STREAM) {
+ EXPECT_EQ(-1, read(client_fd, &buf, 1));
+ EXPECT_EQ(EINVAL, errno);
+ } else {
+ EXPECT_EQ(1, read(client_fd, &buf, 1));
+ EXPECT_EQ('A', buf);
+ }
+
+ EXPECT_EQ(child, waitpid(child, &status, 0));
+ EXPECT_EQ(1, WIFEXITED(status));
+ EXPECT_EQ(EXIT_SUCCESS, WEXITSTATUS(status));
+
+ if (client_fd != bind_fd)
+ EXPECT_LE(0, close(client_fd));
+
+ EXPECT_EQ(0, close(bind_fd));
+}
+
TEST_F(protocol, sendmsg_stream)
{
int srv0_fd, tmp_fd, client_fd, res;
--
2.47.3
^ permalink raw reply related
* Re: [RFC PATCH 1/2] landlock: fix TCP Fast Open connection bypass
From: Matthieu Buffet @ 2026-07-01 21:42 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Bryam Vargas, Günther Noack, linux-security-module,
Mikhail Ivanov, Paul Moore, Eric Dumazet, Neal Cardwell,
linux-kernel, netdev
In-Reply-To: <20260626.taijohThood1@digikod.net>
Hi Mickaël,
On 6/26/2026 10:40 PM, Mickaël Salaün wrote:
> Thanks Matthieu, could you please rebase this serise on the master
> branch (especially on top of your UDP changes)?
Yes I hoped I could send it just in time before the UDP merge, but no
luck. Here is the patch with your feedback, and rebased on next over UDP.
Have a nice day!
--
Matthieu
^ permalink raw reply
* Re: [PATCH v4 bpf-next 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: David Windsor @ 2026-07-01 22:58 UTC (permalink / raw)
To: Paul Moore
Cc: Alexei Starovoitov, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Jiri Olsa,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Matt Bobrowski,
James Morris, Serge E . Hallyn, Casey Schaufler, Stephen Smalley,
Ondrej Mosnacek, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Alexander Viro, Christian Brauner, Jan Kara,
Shuah Khan, bpf, linux-security-module, linux-fsdevel,
linux-integrity, selinux, linux-kselftest, linux-kernel
In-Reply-To: <CAHC9VhT37f5TwgksE_i0Yttpy3i7niBr6QrNVVmpwe_eGX428g@mail.gmail.com>
On Wed, Jul 1, 2026 at 8:55 AM Paul Moore <paul@paul-moore.com> wrote:
[...]
>
> kfunc bpf_init_inode_xattr(...)
> {
> /* sanity check params */
> if (!xattrs ...)
> return -EINVAL;
>
> /* get value/len from bpf dynptr */
>
> /* hook will check for LSM specific xattr count/limits, allocate,
> copy value*/
> rc = security_lsmxattr_add(xattrs, LSM_ID_BPF, value, value_len);
> if (rc)
> return rc;
> }
>
> David, if you like I can provide you a patch that implements the
> security_lsmxattr_add() hook above if you aren't comfortable writing
> that, but if you want to give it a shot that's all the better :)
>
Makes sense, I can do it while I'm fixing the remaining issue flagged
by sashiko.
I'll route the LSM preparation patch containing struct lsm_xattrs and
security_lsmxattr_add() through security and the kfunc and selftest
through bpf. Does that work for you?
Thanks,
David
^ permalink raw reply
* Re: [PATCH v4 bpf-next 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Paul Moore @ 2026-07-01 23:21 UTC (permalink / raw)
To: David Windsor
Cc: Alexei Starovoitov, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Jiri Olsa,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Matt Bobrowski,
James Morris, Serge E . Hallyn, Casey Schaufler, Stephen Smalley,
Ondrej Mosnacek, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Alexander Viro, Christian Brauner, Jan Kara,
Shuah Khan, bpf, linux-security-module, linux-fsdevel,
linux-integrity, selinux, linux-kselftest, linux-kernel
In-Reply-To: <CAEXv5_ig4P=wMoiy4h-TbZt-Wz-YBAs5k6R4szSSxr4C0kjCTw@mail.gmail.com>
On Wed, Jul 1, 2026 at 6:58 PM David Windsor <dwindsor@gmail.com> wrote:
> On Wed, Jul 1, 2026 at 8:55 AM Paul Moore <paul@paul-moore.com> wrote:
> [...]
> >
> > kfunc bpf_init_inode_xattr(...)
> > {
> > /* sanity check params */
> > if (!xattrs ...)
> > return -EINVAL;
> >
> > /* get value/len from bpf dynptr */
> >
> > /* hook will check for LSM specific xattr count/limits, allocate,
> > copy value*/
> > rc = security_lsmxattr_add(xattrs, LSM_ID_BPF, value, value_len);
> > if (rc)
> > return rc;
> > }
> >
> > David, if you like I can provide you a patch that implements the
> > security_lsmxattr_add() hook above if you aren't comfortable writing
> > that, but if you want to give it a shot that's all the better :)
>
> Makes sense, I can do it while I'm fixing the remaining issue flagged
> by sashiko.
>
> I'll route the LSM preparation patch containing struct lsm_xattrs and
> security_lsmxattr_add() through security and the kfunc and selftest
> through bpf. Does that work for you?
Yep.
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 06/20] bpf: lsm: Add Landlock kfuncs
From: Paul Moore @ 2026-07-01 23:32 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Justin Suess, ast, daniel, kpsingh, john.fastabend, andrii, viro,
brauner, kees, gnoack, jack, jmorris, serge, song, yonghong.song,
martin.lau, m, eddyz87, sdf, skhan, bpf, linux-security-module,
linux-kernel, linux-fsdevel, Frederick Lawler
In-Reply-To: <20260701.aeghohNoe3ek@digikod.net>
On Wed, Jul 1, 2026 at 5:28 PM Mickaël Salaün <mic@digikod.net> wrote:
> On Wed, Jul 01, 2026 at 04:02:36PM -0400, Paul Moore wrote:
> > On Wed, Jul 1, 2026 at 3:55 PM Justin Suess <utilityemal77@gmail.com> wrote:
> > > On Wed, Jul 01, 2026 at 09:49:07PM +0200, Mickaël Salaün wrote:
> > > > On Wed, Jul 01, 2026 at 02:38:08PM -0400, Paul Moore wrote:
> > > > > On Wed, Jul 1, 2026 at 2:34 PM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > On Wed, Jul 01, 2026 at 09:28:22AM -0400, Paul Moore wrote:
> > > > > > > On Wed, Jul 1, 2026 at 8:52 AM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > > > > > On Wed, Jul 01, 2026 at 08:12:34AM -0400, Paul Moore wrote:
> > > > > > > > > On Wed, Jul 1, 2026 at 6:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > > > > On Tue, Apr 07, 2026 at 04:01:28PM -0400, Justin Suess wrote:
> > > > > > > > > > > Create 2 kfuncs exposing control over Landlock functionality to BPF
> > > > > > > > > > > callers. Export an opaque struct bpf_landlock_ruleset preventing callers
> > > > > > > > > > > from accessing unstable internal Landlock fields.
> > > > > > > > >
> > > > > > > > > Generally speaking we don't want to provide APIs, either in-kernel or
> > > > > > > > > at the userspace/kernel boundary, that are specific to a single LSM,
> > > > > > > > > see the LSM syscalls or the security_current_getlsmprop_subj()
> > > > > > > > > function as examples.
> > > > > >
> > > > > > This patch series is not about the LSM framework, only about Landlock
> > > > > > and its specific model and use case. Landlock using some of the LSM API
> > > > > > is not relevant here.
> > > > >
> > > > > Based on a quick look the patchset enables BPF programs to call
> > > > > directly into Landlock. For the same reason we discourage other parts
> > > > > of the kernel to call directly into individual LSMs, we want to
> > > > > discourage BPF programs from calling directly into individual LSMs.
> > > >
> > > > We're OK for a dedicated kfunc to call directly into Landlock (with a
> > > > tailored interface). Landlock is designed around its syscall interfaces
> > > > (well documented, tailored, tested), and this would be a new user of
> > > > almost the same UAPI.
> > >
> > > Paul, Mickaël,
> > >
> > > I think there's a cleaner way to resolve this.
> > >
> > > First, walking back my earlier email: I was wrong saying that we need to call
> > > into security/security.c to check whether Landlock is enabled. Landlock's
> > > init only runs when it's in the active lsm= list, so I can just test
> > > landlock_initialized directly. There's no per-invocation reason to route
> > > through the LSM framework for that.
> >
> > The landlock_initialized flag is not really a LSM framework API, that
> > is still Landlock specific which is something we try hard to avoid.
> >
> > > Rather than routing each kfunc *invocation* through a security/security.c
> > > wrapper, I think the right place for the framework to be involved is
> > > *registration*: have the LSM framework own registration of an LSM's
> > > kfunc sets, e.g.
> > >
> > > int security_register_lsm_kfunc_set(u64 lsm_id, enum bpf_prog_type type,
> > > const struct btf_kfunc_id_set *kset);
> >
> > That implies a set of LSM kfunc APIs which Alexei has been deadset
> > against (see other ongoing threads).
> >
> > > Each LSM calls this once to register its sets. Because registration goes
> > > through the framework, the framework gets to decide whether to actually
> > > register them so you could, for example, run an LSM while explicitly
> > > opting its BPF kfuncs out. (something that should be done at the LSM
> > > framework level).
> >
> > I'm not opposed to the LSM supporting a set of kfuncs, see my comments
> > in other threads, but we should treat these kfuncs just as we treat
> > other LSM hooks today because that is what they are: LSM hooks that
> > happened to be called from within a BPF program.
>
> What an LSM hook is or should be is the crux of the misunderstanding. I
> explained my point of view here:
> https://lore.kernel.org/all/20260701.jei4Paej3zen@digikod.net/
>
> LSM hooks make sense because they are designed for a specific subsystem
> (the caller) and their goal is to return an access decision or to keep
> up-to-date related states, which means that their API is designed for
> the caller, with its own types and specificities, not the other way
> around. This case is different, the kfunc is strongly typed and tied to
> the Landlock (subsystem) semantic with an API defined by and for
> Landlock. I don't think a multiplexer would be a good idea.
>
> I'd try to explain better: in a nutshell, an LSM hook exposes a subset
> of the context of the caller, for any access control system to be able
> to make a decision.
That is true for some LSM hooks, but not all of them. LSM hooks are
really just another name for the functions that compose parts of the
LSM framework API; it isn't always strictly about access control in
the kernel. We leverage the "hooks" for the LSM syscalls, we've
discussed "hooks" for implementing a common LSM namespace API, and
there have also been early efforts at LSM policy loading via "hooks".
> It makes sense to have such dispatcher because the
> callees must adapt to the caller's context, and then the API is tailored
> to the caller, so even with several consumers, the API would ultimately
> be the same. In the case of this kfunc, the callee is one specific
> subsystem that happens to be Landlock. The caller asks a specific
> subsystem to do something specific to this subsystem, not to ask all
> potential access control systems to give a generic verdict to grant an
> access or not.
> For this kfunc, the caller passes arguments which are
> specific to the callee subsystem (e.g. a Landlock ruleset), not the
> other way around. Every LSM has its own configuration, and it doesn't
> make sense to somehow wrap these configurations with a common layer/API.
Once again, there have already been discussions about trying to build
a common API for that. I'd rather have us pick that up for an
in-kernel/kfunc users than treat Landlock as an exception. We're
trying to get rid of the exceptions in the LSM space.
> Why not start with something simple that fits a use case now? If and
> when another LSM will need a kfunc, then we'll have something concrete
> to talk about.
I think Casey's reply answers that question rather well.
--
paul-moore.com
^ permalink raw reply
* [PATCH v2] selftests/landlock: fix spelling error in fs_test comment
From: Wang Yan @ 2026-07-02 1:58 UTC (permalink / raw)
To: mic, gnoack, shuah
Cc: linux-security-module, linux-kselftest, linux-kernel, Wang Yan
Fix typo "allowes" -> "allows" in Landlock filesystem test comment.
Signed-off-by: Wang Yan <wangyan01@kylinos.cn>
---
tools/testing/selftests/landlock/fs_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
index 86e08aa6e0a7..e672089e9329 100644
--- a/tools/testing/selftests/landlock/fs_test.c
+++ b/tools/testing/selftests/landlock/fs_test.c
@@ -6927,7 +6927,7 @@ TEST_F_FORK(layout2_overlay, same_content_different_file)
ASSERT_EQ(0, test_open(path_entry, O_RDWR));
}
- /* Only allowes access to the merge hierarchy. */
+ /* Only allows access to the merge hierarchy. */
enforce_fs(_metadata, ACCESS_RW, layer5_merge_only);
/* Checks new accesses on lower layer. */
--
2.25.1
^ permalink raw reply related
* Re: [RFC PATCH 0/4] Introduce capable_noaudit
From: Christian Brauner @ 2026-07-02 7:41 UTC (permalink / raw)
To: cem
Cc: linux-fsdevel, jack, djwong, hch, serge, linux-security-module,
linux-kernel, linux-xfs
In-Reply-To: <20260626114533.102138-1-cem@kernel.org>
On 2026-06-26 13:45 +0200, cem@kernel.org wrote:
> From: Carlos Maiolino <cem@kernel.org>
>
> In some cases - filesystems quota specifically here - we'd like to check
> for effective capabilities without issuing spurious audit messages and
> without the need to specify a namespace for that.
>
> This series introduce capable_noaudit() which has the same goal as
> capable() but without firing audit messages.
>
> Also, this updates both generic quota and xfs quota code to use that.
>
> The last patch unexports has_capability_noaudit() which was originally
> exported to be used in xfs but turns out it does not meet our needs.
>
> Note this is based on top of a current series I have to remove
> has_capability_noaudit() calls from xfs so the xfs patch won't
> apply cleanly without that series.
>
> If adding this helper is acceptable, I'll turn this into a non-rfc
> series with the required changes to apply properly.
>
> Comments? Flames?
Convert more, please.
^ permalink raw reply
* Re: [RFC PATCH 1/4] capabily: Add new capable_noaudit
From: Carlos Maiolino @ 2026-07-02 7:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-fsdevel, jack, djwong, serge, linux-security-module,
linux-kernel, linux-xfs
In-Reply-To: <20260629122939.GA21958@lst.de>
On Mon, Jun 29, 2026 at 02:29:39PM +0200, Christoph Hellwig wrote:
> On Fri, Jun 26, 2026 at 01:45:20PM +0200, cem@kernel.org wrote:
> > +extern bool capable_noaudit(int cap);
>
> No need for the extern.
Indeed, I was just being consistent with the rest of the file :P
>
> Otherwise this does look nice an clean to me:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
> But if the security folks don't like we can live with the more
> verbose version of it I guess.
>
>
^ permalink raw reply
* Re: [RFC PATCH 0/4] Introduce capable_noaudit
From: Carlos Maiolino @ 2026-07-02 8:35 UTC (permalink / raw)
To: Christian Brauner
Cc: linux-fsdevel, jack, djwong, hch, serge, linux-security-module,
linux-kernel, linux-xfs
In-Reply-To: <20260702-alufelgen-belag-tastatur-b666a49f7fc0@brauner>
On Thu, Jul 02, 2026 at 09:41:39AM +0200, Christian Brauner wrote:
> On 2026-06-26 13:45 +0200, cem@kernel.org wrote:
> > From: Carlos Maiolino <cem@kernel.org>
> >
> > In some cases - filesystems quota specifically here - we'd like to check
> > for effective capabilities without issuing spurious audit messages and
> > without the need to specify a namespace for that.
> >
> > This series introduce capable_noaudit() which has the same goal as
> > capable() but without firing audit messages.
> >
> > Also, this updates both generic quota and xfs quota code to use that.
> >
> > The last patch unexports has_capability_noaudit() which was originally
> > exported to be used in xfs but turns out it does not meet our needs.
> >
> > Note this is based on top of a current series I have to remove
> > has_capability_noaudit() calls from xfs so the xfs patch won't
> > apply cleanly without that series.
> >
> > If adding this helper is acceptable, I'll turn this into a non-rfc
> > series with the required changes to apply properly.
> >
> > Comments? Flames?
>
> Convert more, please.
>
Convert what? :) more callers from capable() to capable_noaudit()?
^ permalink raw reply
* Re: [PATCH v2] selftests/landlock: fix spelling error in fs_test comment
From: Günther Noack @ 2026-07-02 9:05 UTC (permalink / raw)
To: Wang Yan; +Cc: mic, shuah, linux-security-module, linux-kselftest, linux-kernel
In-Reply-To: <20260702015823.368529-1-wangyan01@kylinos.cn>
On Thu, Jul 02, 2026 at 09:58:23AM +0800, Wang Yan wrote:
> Fix typo "allowes" -> "allows" in Landlock filesystem test comment.
>
> Signed-off-by: Wang Yan <wangyan01@kylinos.cn>
> ---
> tools/testing/selftests/landlock/fs_test.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
> index 86e08aa6e0a7..e672089e9329 100644
> --- a/tools/testing/selftests/landlock/fs_test.c
> +++ b/tools/testing/selftests/landlock/fs_test.c
> @@ -6927,7 +6927,7 @@ TEST_F_FORK(layout2_overlay, same_content_different_file)
> ASSERT_EQ(0, test_open(path_entry, O_RDWR));
> }
>
> - /* Only allowes access to the merge hierarchy. */
> + /* Only allows access to the merge hierarchy. */
> enforce_fs(_metadata, ACCESS_RW, layer5_merge_only);
>
> /* Checks new accesses on lower layer. */
> --
> 2.25.1
>
Reviewed-by: Günther Noack <gnoack@google.com>
^ permalink raw reply
* [PATCH v3 0/5] Fix quota evasion on xfs and add capable_noaudit
From: cem @ 2026-07-02 9:33 UTC (permalink / raw)
To: cem
Cc: Jan Kara, Christoph Hellwig, Serge E. Hallyn, Darrick J. Wong,
Dave Chinner, Eric Sandeen, linux-xfs, linux-fsdevel,
linux-security-module, linux-kernel
From: Carlos Maiolino <cem@kernel.org>
Hi there.
This is the (hopefully) final version of the series I've been working on
to fix a quota evasion issue on xfs. This bug has originally been
introduced by accident while turning off audit messages while checking
quota limits in xfs by replacing capable() calls by has_capability_noaudit().
This series concatenates both series I sent for xfs and capabilities
infrastructure as they are dependent.
The first patch fix the xfs bug in a way that makes it easily portable
to older LTS kernels.
From second patch and beyond, it adds a new helper for the capabilities
framework named capable_noaudit() which as the same semantics as
capable() but without generating audit messages.
The following patches then replaces both generic quota call to
capable() and properly update xfs code to use this new helper.
Last but not least this unexport has_capability_noaudit which had been
previously exported.
Giving this affects different subsystems, I think it would be easier to
pull everything from a single tree (as long as everything is properly
reviewed of course).
Serge, Honza, are you guys ok if I pull those patches and send them to
Linus through xfs tree so we don't need to split the series?
Christoph, this series moves back to pass the capable_noaudit() result
straight back to xfs_trans_alloc_ichange() instead of moving the
capability check into xfs_trans_dqresv() as Darrick was not in agreement
with that (patch unreviewed and open for comments).
Changelog from the last state of these patches:
Patch2: removed the redundant external classifier from the declaration
in include/linux/capability.h.
Serge, I kept your RwB here as the external is redundant, please
let me know if you are ok with it or not.
Patch4: Replace all ns_capable_noaudit() calls by capable_noaudit() and
keep the CAP_FOWNER (instead replacing it by SYS_RESOURCE)
Carlos Maiolino (5):
xfs: fix capability check in xfs
capability: Add new capable_noaudit
quota: Don't issue audit messages on quota enforcing
xfs: replace ns_capable_noaudit
capability: unexport has_capability_noaudit
fs/quota/dquot.c | 2 +-
fs/xfs/xfs_fsmap.c | 3 +--
fs/xfs/xfs_ioctl.c | 2 +-
fs/xfs/xfs_iops.c | 3 ++-
include/linux/capability.h | 5 +++++
kernel/capability.c | 18 +++++++++++++++++-
6 files changed, 27 insertions(+), 6 deletions(-)
Cc: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Serge E. Hallyn <serge@hallyn.com>
Cc: Darrick J. Wong <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@redhat.com>
Cc: Dr. Thomas Orgis" <thomas.orgis@uni-hamburg.de>
Cc: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
--
2.54.0
^ permalink raw reply
* [PATCH v3 1/5] xfs: fix capability check in xfs
From: cem @ 2026-07-02 9:33 UTC (permalink / raw)
To: cem
Cc: stable, Jan Kara, Christoph Hellwig, Serge E. Hallyn,
Darrick J. Wong, Dave Chinner, Eric Sandeen, linux-xfs,
linux-fsdevel, linux-security-module, linux-kernel,
Dr. Thomas Orgis
In-Reply-To: <20260702093324.127450-1-cem@kernel.org>
From: Carlos Maiolino <cem@kernel.org>
An user reported a bug where he managed to evade group's quota
by changing a file's gid to a different group id the same user
belonged to, even though quotas were enforced on both gids and the
file's size was big enough to exceed the quota's hardlimit.
Commit eba0549bc7d1 replaced a capable() call by a
has_capability_noaudit() to prevent unnecessary selinux audit messages.
Turns out that both calls have slightly different semantics even though
their documentation seems similar. Where in a nutshell:
capable() - Tests the task's effective credentials
has_ns_capability_noaudit() - Tests the task's real credentials
This most of the time has no practical difference but in some cases like
changing attrs (specifically group id in this case) through a NFS client
this will allow the quota code to use XFS_QMOPT_FORCE_RES, effectively
bypassing quota accounting checks.
Using instead ns_capable_noaudit() should fix this issue and prevent
selinux audit messages.
This also fix the remaining calls to has_capability_noaudit()
Fixes: eba0549bc7d1 ("xfs: don't generate selinux audit messages for capability testing")
Cc: <stable@vger.kernel.org> # v5.18
Cc: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Serge E. Hallyn <serge@hallyn.com>
Cc: Darrick J. Wong <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@redhat.com>
Cc: Dr. Thomas Orgis" <thomas.orgis@uni-hamburg.de>
Cc: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reported-by: Dr. Thomas Orgis <thomas.orgis@uni-hamburg.de>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
---
fs/xfs/xfs_fsmap.c | 2 +-
fs/xfs/xfs_ioctl.c | 2 +-
fs/xfs/xfs_iops.c | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_fsmap.c b/fs/xfs/xfs_fsmap.c
index b6a3bc9f143c..7c79fbe0a74c 100644
--- a/fs/xfs/xfs_fsmap.c
+++ b/fs/xfs/xfs_fsmap.c
@@ -1175,7 +1175,7 @@ xfs_getfsmap(
return -EINVAL;
use_rmap = xfs_has_rmapbt(mp) &&
- has_capability_noaudit(current, CAP_SYS_ADMIN);
+ ns_capable_noaudit(&init_user_ns, CAP_SYS_ADMIN);
head->fmh_entries = 0;
/* Set up our device handlers. */
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index 1b53701bebea..1a8af827dde1 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -647,7 +647,7 @@ xfs_ioctl_setattr_get_trans(
goto out_error;
error = xfs_trans_alloc_ichange(ip, NULL, NULL, pdqp,
- has_capability_noaudit(current, CAP_FOWNER), &tp);
+ ns_capable_noaudit(&init_user_ns, CAP_FOWNER), &tp);
if (error)
goto out_error;
diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index 6339f4956ecb..205fe2dae732 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -835,7 +835,8 @@ xfs_setattr_nonsize(
}
error = xfs_trans_alloc_ichange(ip, udqp, gdqp, NULL,
- has_capability_noaudit(current, CAP_FOWNER), &tp);
+ ns_capable_noaudit(&init_user_ns, CAP_FOWNER),
+ &tp);
if (error)
goto out_dqrele;
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox