From: Jeff Layton <jlayton@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Josef Bacik <josef@toxicpanda.com>,
linux-fsdevel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 7/8] fs: add an ioctl to get the mnt ns id from nsfs
Date: Tue, 25 Jun 2024 10:50:57 -0400 [thread overview]
Message-ID: <1833a18f7935aed5df264ed295d1084672234541.camel@kernel.org> (raw)
In-Reply-To: <20240625-darunter-wieweit-9ced87b1df0b@brauner>
On Tue, 2024-06-25 at 16:21 +0200, Christian Brauner wrote:
> On Tue, Jun 25, 2024 at 10:10:29AM GMT, Jeff Layton wrote:
> > On Mon, 2024-06-24 at 11:49 -0400, Josef Bacik wrote:
> > > In order to utilize the listmount() and statmount() extensions that
> > > allow us to call them on different namespaces we need a way to get
> > > the
> > > mnt namespace id from user space. Add an ioctl to nsfs that will
> > > allow
> > > us to extract the mnt namespace id in order to make these new
> > > extensions
> > > usable.
> > >
> > > Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> > > ---
> > > fs/nsfs.c | 14 ++++++++++++++
> > > include/uapi/linux/nsfs.h | 2 ++
> > > 2 files changed, 16 insertions(+)
> > >
> > > diff --git a/fs/nsfs.c b/fs/nsfs.c
> > > index 07e22a15ef02..af352dadffe1 100644
> > > --- a/fs/nsfs.c
> > > +++ b/fs/nsfs.c
> > > @@ -12,6 +12,7 @@
> > > #include <linux/nsfs.h>
> > > #include <linux/uaccess.h>
> > >
> > > +#include "mount.h"
> > > #include "internal.h"
> > >
> > > static struct vfsmount *nsfs_mnt;
> > > @@ -143,6 +144,19 @@ static long ns_ioctl(struct file *filp, unsigned
> > > int ioctl,
> > > argp = (uid_t __user *) arg;
> > > uid = from_kuid_munged(current_user_ns(), user_ns-
> > > > owner);
> > > return put_user(uid, argp);
> > > + case NS_GET_MNTNS_ID: {
> > > + struct mnt_namespace *mnt_ns;
> > > + __u64 __user *idp;
> > > + __u64 id;
> > > +
> > > + if (ns->ops->type != CLONE_NEWNS)
> > > + return -EINVAL;
> > > +
> > > + mnt_ns = container_of(ns, struct mnt_namespace, ns);
> > > + idp = (__u64 __user *)arg;
> > > + id = mnt_ns->seq;
> > > + return put_user(id, idp);
> > > + }
> > > default:
> > > return -ENOTTY;
> > > }
> > > diff --git a/include/uapi/linux/nsfs.h b/include/uapi/linux/nsfs.h
> > > index a0c8552b64ee..56e8b1639b98 100644
> > > --- a/include/uapi/linux/nsfs.h
> > > +++ b/include/uapi/linux/nsfs.h
> > > @@ -15,5 +15,7 @@
> > > #define NS_GET_NSTYPE _IO(NSIO, 0x3)
> > > /* Get owner UID (in the caller's user namespace) for a user
> > > namespace */
> > > #define NS_GET_OWNER_UID _IO(NSIO, 0x4)
> > > +/* Get the id for a mount namespace */
> > > +#define NS_GET_MNTNS_ID _IO(NSIO, 0x5)
> > >
> > > #endif /* __LINUX_NSFS_H */
> >
> > Thinking about this more...
> >
> > Would it also make sense to wire up a similar ioctl in pidfs? It seems
> > like it might be nice to just open a pidfd for pid and then issue the
> > above to get its mntns id, rather than having to grovel around in nsfs.
>
> I had a different idea yesterday: get a mount namespace fd from a pidfd
> in fact, get any namespace fd based on a pidfd. It's the equivalent to:
> /proc/$pid/ns* and then you can avoid having to go via procfs at all.
That would work too. I'd specifically like to be able to avoid crawling
around in /proc/<pid> as much as possible.
At this point, I think we're still stuck with having to walk /proc to
know what pids currently exist though, right? I don't think there is
any way to walk all the pids just using pidfds is there?
>
> Needs to be governed by ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS).
>
> (We also need an ioctl() on the pidfd to get to the PID without procfs btw.
A PIDFS_GET_PID ioctl seems like a reasonable thing to add.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2024-06-25 14:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-24 15:49 [PATCH 0/8] Support foreign mount namespace with statmount/listmount Josef Bacik
2024-06-24 15:49 ` [PATCH 1/8] fs: relax permissions for listmount() Josef Bacik
2024-06-24 15:49 ` [PATCH 2/8] fs: relax permissions for statmount() Josef Bacik
2024-06-24 15:49 ` [PATCH 3/8] fs: keep an index of current mount namespaces Josef Bacik
2024-06-25 13:03 ` Jeff Layton
2024-06-25 13:39 ` Christian Brauner
2024-06-24 15:49 ` [PATCH 4/8] fs: export the mount ns id via statmount Josef Bacik
2024-06-24 15:49 ` [PATCH 5/8] fs: Allow listmount() in foreign mount namespace Josef Bacik
2024-06-24 15:49 ` [PATCH 6/8] fs: Allow statmount() " Josef Bacik
2024-06-24 15:49 ` [PATCH 7/8] fs: add an ioctl to get the mnt ns id from nsfs Josef Bacik
2024-06-25 14:10 ` Jeff Layton
2024-06-25 14:21 ` Christian Brauner
2024-06-25 14:50 ` Jeff Layton [this message]
2024-06-25 15:02 ` Christian Brauner
2024-07-30 16:45 ` Dmitry V. Levin
2024-07-31 5:51 ` Christian Brauner
2024-06-24 15:49 ` [PATCH 8/8] selftests: add a test for the foreign mnt ns extensions Josef Bacik
2024-06-25 13:37 ` [PATCH 0/8] Support foreign mount namespace with statmount/listmount Jeff Layton
2024-06-25 14:00 ` Christian Brauner
2024-06-25 20:15 ` Karel Zak
2024-06-26 12:03 ` Christian Brauner
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=1833a18f7935aed5df264ed295d1084672234541.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=brauner@kernel.org \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-fsdevel@vger.kernel.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 NNTP newsgroup(s).