From: Shyam Prasad N <nspmangalore@gmail.com>
To: David Leadbeater <dgl@dgl.cx>
Cc: lsf-pc@lists.linux-foundation.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
keyrings@vger.kernel.org, CIFS <linux-cifs@vger.kernel.org>,
linux-nfs@vger.kernel.org, brauner@kernel.org,
David Howells <dhowells@redhat.com>
Subject: Re: [LSF/MM/BPF TOPIC] Namespace-aware upcalls from kernel filesystems
Date: Tue, 17 Feb 2026 09:46:41 +0530 [thread overview]
Message-ID: <CANT5p=p6yw3eYJVXZc2CA2fBgBYpZ4W0uKivt2tCmtgos3GVdw@mail.gmail.com> (raw)
In-Reply-To: <aZJmthYtk33KYDud@melos.hm.i.d.cx>
On Mon, Feb 16, 2026 at 6:25 AM David Leadbeater <dgl@dgl.cx> wrote:
>
> On Sat, Feb 14, 2026 at 03:36:22PM +0530, Shyam Prasad N wrote:
> > I tried to prototype a namespace aware upcall mechanism for kernel keys here:
> > https://www.spinics.net/lists/keyrings/msg17581.html
> > But it has not been successful so far. I'm seeking reviews on this
> > approach from security point of view.
>
> I have more context from the containers side, but to me this doesn't
> appear safe. Entering the right namespaces isn't enough to safely run
> code within a container. The container runtime may have set up seccomp
> or other limits which this upcall won't respect.
Hi David,
Thanks for these comments.
Let me look into seccomp to see if kernel will have any visibility into it.
>
> I would like to see a solution to this though, we currently have custom
> callback code to make this work. I'm not familiar enough with the
> interfaces but an approach where something registers also seems
> desirable because it is able to preserve backwards compatibility, which
> changing the namespace the upcall runs in doesn't.
Ack. Will explore the options and get back to this thread.
>
> David
>
--
Regards,
Shyam
prev parent reply other threads:[~2026-02-17 4:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-14 10:06 [LSF/MM/BPF TOPIC] Namespace-aware upcalls from kernel filesystems Shyam Prasad N
2026-02-14 15:39 ` Chuck Lever
2026-02-17 4:14 ` Shyam Prasad N
2026-02-17 14:21 ` Chuck Lever
2026-02-17 15:18 ` Jeff Layton
2026-02-24 3:31 ` Shyam Prasad N
2026-02-24 8:35 ` Christian Brauner
2026-02-24 3:15 ` Shyam Prasad N
2026-02-16 0:48 ` David Leadbeater
2026-02-17 4:16 ` Shyam Prasad N [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='CANT5p=p6yw3eYJVXZc2CA2fBgBYpZ4W0uKivt2tCmtgos3GVdw@mail.gmail.com' \
--to=nspmangalore@gmail.com \
--cc=brauner@kernel.org \
--cc=dgl@dgl.cx \
--cc=dhowells@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).