From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, linux-man@vger.kernel.org,
linux-security-module@vger.kernel.org,
Karel Zak <kzak@redhat.com>, Ian Kent <raven@themaw.net>,
David Howells <dhowells@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <christian@brauner.io>
Subject: Re: [RFC PATCH 3/3] add listmnt(2) syscall
Date: Thu, 14 Sep 2023 09:00:17 +0300 [thread overview]
Message-ID: <CAOQ4uxh4ETADj7cD56d=8+0t7L_DHaSQpoPGHmwHFqCreOQjdQ@mail.gmail.com> (raw)
In-Reply-To: <20230913152238.905247-4-mszeredi@redhat.com>
On Wed, Sep 13, 2023 at 6:22 PM Miklos Szeredi <mszeredi@redhat.com> wrote:
>
> Add way to query the children of a particular mount. This is a more
> flexible way to iterate the mount tree than having to parse the complete
> /proc/self/mountinfo.
>
> Lookup the mount by the old (32bit) or new (64bit) mount ID. If a mount
> needs to be queried based on path, then statx(2) can be used to first query
> the mount ID belonging to the path.
>
> Return an array of new (64bit) mount ID's. Without privileges only mounts
> are listed which are reachable from the task's root.
>
> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
> ---
> arch/x86/entry/syscalls/syscall_64.tbl | 1 +
> fs/namespace.c | 51 ++++++++++++++++++++++++++
> include/linux/syscalls.h | 2 +
> include/uapi/asm-generic/unistd.h | 5 ++-
> 4 files changed, 58 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
> index 6d807c30cd16..0d9a47b0ce9b 100644
> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> @@ -376,6 +376,7 @@
> 452 common fchmodat2 sys_fchmodat2
> 453 64 map_shadow_stack sys_map_shadow_stack
> 454 common statmnt sys_statmnt
> +455 common listmnt sys_listmnt
>
> #
> # Due to a historical design error, certain syscalls are numbered differently
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 088a52043bba..5362b1ffb26f 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -4988,6 +4988,57 @@ SYSCALL_DEFINE5(statmnt, u64, mnt_id,
> return err;
> }
>
> +static long do_listmnt(struct vfsmount *mnt, u64 __user *buf, size_t bufsize,
> + const struct path *root)
> +{
> + struct mount *r, *m = real_mount(mnt);
> + struct path rootmnt = { .mnt = root->mnt, .dentry = root->mnt->mnt_root };
> + long ctr = 0;
> +
> + if (!capable(CAP_SYS_ADMIN) &&
> + !is_path_reachable(m, mnt->mnt_root, &rootmnt))
> + return -EPERM;
> +
> + list_for_each_entry(r, &m->mnt_mounts, mnt_child) {
> + if (!capable(CAP_SYS_ADMIN) &&
> + !is_path_reachable(r, r->mnt.mnt_root, root))
> + continue;
> +
> + if (ctr >= bufsize)
> + return -EOVERFLOW;
> + if (put_user(r->mnt_id_unique, buf + ctr))
> + return -EFAULT;
> + ctr++;
> + if (ctr < 0)
> + return -ERANGE;
I think it'd be good for userspace to be able to query required
bufsize with NULL buf, listattr style, rather than having to
guess and re-guess on EOVERFLOW.
Thanks,
Amir.
> + }
> + return ctr;
> +}
> +
> +SYSCALL_DEFINE4(listmnt, u64, mnt_id, u64 __user *, buf, size_t, bufsize,
> + unsigned int, flags)
> +{
> + struct vfsmount *mnt;
> + struct path root;
> + long err;
> +
> + if (flags)
> + return -EINVAL;
> +
> + down_read(&namespace_sem);
> + mnt = lookup_mnt_in_ns(mnt_id, current->nsproxy->mnt_ns);
> + err = -ENOENT;
> + if (mnt) {
> + get_fs_root(current->fs, &root);
> + err = do_listmnt(mnt, buf, bufsize, &root);
> + path_put(&root);
> + }
> + up_read(&namespace_sem);
> +
> + return err;
> +}
> +
> +
> static void __init init_mount_tree(void)
> {
> struct vfsmount *mnt;
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index 1099bd307fa7..5d776cdb6f18 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -411,6 +411,8 @@ asmlinkage long sys_fstatfs64(unsigned int fd, size_t sz,
> asmlinkage long sys_statmnt(u64 mnt_id, u64 mask,
> struct statmnt __user *buf, size_t bufsize,
> unsigned int flags);
> +asmlinkage long sys_listmnt(u64 mnt_id, u64 __user *buf, size_t bufsize,
> + unsigned int flags);
> asmlinkage long sys_truncate(const char __user *path, long length);
> asmlinkage long sys_ftruncate(unsigned int fd, unsigned long length);
> #if BITS_PER_LONG == 32
> diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
> index 640997231ff6..a2b41370f603 100644
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
> @@ -826,8 +826,11 @@ __SYSCALL(__NR_fchmodat2, sys_fchmodat2)
> #define __NR_statmnt 454
> __SYSCALL(__NR_statmnt, sys_statmnt)
>
> +#define __NR_listmnt 455
> +__SYSCALL(__NR_listmnt, sys_listmnt)
> +
> #undef __NR_syscalls
> -#define __NR_syscalls 455
> +#define __NR_syscalls 456
>
> /*
> * 32 bit systems traditionally used different
> --
> 2.41.0
>
next prev parent reply other threads:[~2023-09-14 6:00 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-13 15:22 [RFC PATCH 0/3] quering mount attributes Miklos Szeredi
2023-09-13 15:22 ` [RFC PATCH 1/3] add unique mount ID Miklos Szeredi
2023-09-14 9:03 ` Christian Brauner
2023-09-14 9:30 ` Miklos Szeredi
2023-09-14 9:36 ` Christian Brauner
2023-09-14 9:43 ` Miklos Szeredi
2023-09-14 10:06 ` Christian Brauner
2023-09-15 1:31 ` Ian Kent
2023-09-13 15:22 ` [RFC PATCH 2/3] add statmnt(2) syscall Miklos Szeredi
2023-09-14 6:11 ` Amir Goldstein
2023-09-15 1:05 ` Ian Kent
2023-09-14 9:27 ` Christian Brauner
2023-09-14 10:13 ` Miklos Szeredi
2023-09-14 15:26 ` Christian Brauner
2023-09-15 8:56 ` Miklos Szeredi
2023-09-18 13:51 ` Christian Brauner
2023-09-18 14:14 ` Miklos Szeredi
2023-09-18 14:24 ` Christian Brauner
2023-09-18 14:32 ` Miklos Szeredi
2023-09-18 14:40 ` Christian Brauner
2023-09-18 14:51 ` Miklos Szeredi
2023-09-18 15:22 ` Christian Brauner
2023-09-18 15:39 ` Miklos Szeredi
2023-09-19 0:37 ` Matthew House
2023-09-19 8:02 ` Miklos Szeredi
2023-09-19 9:07 ` Christian Brauner
2023-09-19 10:51 ` Miklos Szeredi
2023-09-19 12:41 ` Christian Brauner
2023-09-19 12:59 ` Miklos Szeredi
2023-09-19 13:18 ` Christian Brauner
2023-09-19 21:28 ` Matthew House
2023-09-20 9:42 ` Miklos Szeredi
2023-09-20 13:26 ` Matthew House
2023-09-21 7:34 ` Miklos Szeredi
2023-09-26 13:48 ` Florian Weimer
2023-09-26 14:06 ` Miklos Szeredi
2023-09-26 14:19 ` Florian Weimer
2023-09-26 14:33 ` Miklos Szeredi
2023-09-26 14:39 ` Florian Weimer
2023-09-26 14:36 ` Christian Brauner
2023-09-26 14:13 ` Christian Brauner
2023-09-18 20:58 ` Andreas Dilger
2023-09-19 12:50 ` Christian Brauner
2023-09-20 0:33 ` Dave Chinner
2023-09-18 14:29 ` Jeff Layton
2023-09-18 14:35 ` Christian Brauner
2023-09-20 9:43 ` David Laight
2023-09-14 20:39 ` Paul Moore
2023-09-15 9:10 ` Miklos Szeredi
2023-09-17 18:18 ` Sargun Dhillon
2023-09-17 23:36 ` Ian Kent
2023-09-18 13:05 ` Christian Brauner
2023-09-25 12:57 ` Arnd Bergmann
2023-09-25 13:04 ` Christian Brauner
2023-09-25 13:13 ` Miklos Szeredi
2023-09-25 13:19 ` Christian Brauner
2023-09-25 13:20 ` Miklos Szeredi
2023-09-25 15:46 ` Arnd Bergmann
2023-09-26 10:05 ` Christian Brauner
2023-09-27 8:46 ` Miklos Szeredi
2023-09-13 15:22 ` [RFC PATCH 3/3] add listmnt(2) syscall Miklos Szeredi
2023-09-14 6:00 ` Amir Goldstein [this message]
2023-09-14 8:50 ` Miklos Szeredi
2023-09-14 10:01 ` Christian Brauner
2023-09-15 1:00 ` Ian Kent
2023-09-17 0:54 ` Matthew House
2023-09-17 14:32 ` Miklos Szeredi
2023-09-18 13:15 ` Christian Brauner
2023-09-19 16:47 ` Paul Moore
2023-09-28 10:07 ` Miklos Szeredi
2023-10-04 19:22 ` Paul Moore
2023-09-14 6:47 ` [RFC PATCH 0/3] quering mount attributes Amir Goldstein
2023-09-15 1:20 ` Ian Kent
2023-09-15 3:06 ` Amir Goldstein
2023-09-16 2:04 ` Ian Kent
2023-09-16 2:19 ` Ian Kent
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='CAOQ4uxh4ETADj7cD56d=8+0t7L_DHaSQpoPGHmwHFqCreOQjdQ@mail.gmail.com' \
--to=amir73il@gmail.com \
--cc=christian@brauner.io \
--cc=dhowells@redhat.com \
--cc=kzak@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mszeredi@redhat.com \
--cc=raven@themaw.net \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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).