From: Shyam Prasad N <nspmangalore@gmail.com>
To: David Howells <dhowells@redhat.com>,
Steve French <smfrench@gmail.com>,
brauner@kernel.org
Cc: keyrings@vger.kernel.org, CIFS <linux-cifs@vger.kernel.org>,
Ritvik Budhiraja <budhirajaritviksmb@gmail.com>,
Bharath SM <bharathsm.hsk@gmail.com>
Subject: Keyrings and namespaces
Date: Sat, 19 Oct 2024 16:35:26 +0530 [thread overview]
Message-ID: <CANT5p=qXE3JeX-iaye1UeFvXGkvJwEoSw_pzz5Crq=uTFdVniA@mail.gmail.com> (raw)
Hi David,
On the Linux SMB client, we've recently been dealing with some issues
relating to namespaces for containers that access the cifs mounts. For
several upcalls that we use, we allocate a seperate thread keyring,
prepare_kernel_cred to create a new cred, and temporarily override the
cred for the current process before we call request_key (which
eventually can upcall into userspace).
However, with the current design, we always upcall into the host
namespace. We then have to perform any namespace switch in the
userspace (which we do today for some type of upcalls). However, this
does not seem ideal.
From the man page references, it sounds like each user namespace has
it's own set of keyrings. So it only sounds logical that we use the
keyring belonging to the correct user namespace.
We ran some experiments by using the right cred->user_ns for our
upcalls, and it seems like we still always upcall to the host user
namespace. After reading the request_key code in more detail, it looks
like we use the cred->user_ns field only if the dest keyring is a user
or user-session keyring. I wanted to understand more why all keyring
types cannot make use of user_ns too?
Also, why do creds only contain the user_ns as a field? What about the
rest of the namespace types?
--
Regards,
Shyam
reply other threads:[~2024-10-19 11:05 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=qXE3JeX-iaye1UeFvXGkvJwEoSw_pzz5Crq=uTFdVniA@mail.gmail.com' \
--to=nspmangalore@gmail.com \
--cc=bharathsm.hsk@gmail.com \
--cc=brauner@kernel.org \
--cc=budhirajaritviksmb@gmail.com \
--cc=dhowells@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=smfrench@gmail.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 read-only IMAP folder(s) and NNTP newsgroup(s).