From: Shyam Prasad N <nspmangalore@gmail.com>
To: lsf-pc@lists.linux-foundation.org
Cc: 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: [LSF/MM/BPF TOPIC] Namespace-aware upcalls from kernel filesystems
Date: Sat, 14 Feb 2026 15:36:22 +0530 [thread overview]
Message-ID: <CANT5p=rDxeYKXoCJoWRwGGXv4tPCM2OuX+US_G3hm_tL3UyqtA@mail.gmail.com> (raw)
Kernel filesystems sometimes need to upcall to userspace to get some
work done, which cannot be achieved in kernel code (or rather it is
better to be done in userspace). Some examples are DNS resolutions,
user authentication, ID mapping etc.
Filesystems like SMB and NFS clients use the kernel keys subsystem for
some of these, which has an upcall facility that can exec a binary in
userspace. However, this upcall mechanism is not namespace aware and
upcalls to the host namespaces (namespaces of the init process).
This can be an inconvenience or a blocker for container services,
which run most code from containers and do not like to host any
binaries in the host namespace. They now need to host an upcall
handler in the host namespace, which can switch to the appropriate
namespaces based on the parameters sent before getting the work done.
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.
Another option that I could think of is to host a device file in
devfs. The mount could register with keys subsystem by keeping an FD
open from inside a container. The keys subsystem could then upcall on
the "right" FD based on some parameter supplied to it.
Looking forward to hearing if there is a better approach to solving
this problem.
--
Regards,
Shyam
next reply other threads:[~2026-02-14 10:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-14 10:06 Shyam Prasad N [this message]
2026-02-14 15:39 ` [LSF/MM/BPF TOPIC] Namespace-aware upcalls from kernel filesystems 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
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=rDxeYKXoCJoWRwGGXv4tPCM2OuX+US_G3hm_tL3UyqtA@mail.gmail.com' \
--to=nspmangalore@gmail.com \
--cc=brauner@kernel.org \
--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).