[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOssrKcECS_CvifP1vMM8YOyMW7dkGXTDTKY2CRr-fPrJk76ZA@mail.gmail.com>
Date: Sun, 17 Sep 2023 16:32:04 +0200
From: Miklos Szeredi <mszeredi@...hat.com>
To: Matthew House <mattlloydhouse@...il.com>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-api@...r.kernel.org, linux-man@...r.kernel.org,
linux-security-module@...r.kernel.org, Karel Zak <kzak@...hat.com>,
Ian Kent <raven@...maw.net>,
David Howells <dhowells@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Christian Brauner <christian@...uner.io>,
Amir Goldstein <amir73il@...il.com>
Subject: Re: [RFC PATCH 3/3] add listmnt(2) syscall
On Sun, Sep 17, 2023 at 2:54 AM Matthew House <mattlloydhouse@...il.com> wrote:
> > + 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;
>
> I'm not an expert on the kernel API, but to my eyes, it looks a bit weird
> to silently include or exclude unreachable mounts from the list based on
> the result of a capability check. I'd normally expect a more explicit
> design, where (e.g.) the caller would set a flag to request unreachable
> mounts, then get an -EPERM back if it didn't have the capability, as
> opposed to this design, where the meaning of the output ("all mounts" vs.
> "all reachable mounts") changes implicitly depending on the caller. Is
> there any precedent for a design like this, where inaccessible results
> are silently omitted from a returned list?
Good point. That issue was nagging at the back of my mind. Having an
explicit flag nicely solves the issue.
Thanks,
Miklos
Powered by blists - more mailing lists