[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpeguXPmw+PfZJFOscGLm0oe7dUQY4CYXazx9=x020Fbe86A@mail.gmail.com>
Date: Fri, 28 Feb 2020 09:35:17 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Ian Kent <raven@...maw.net>
Cc: Karel Zak <kzak@...hat.com>, Miklos Szeredi <mszeredi@...hat.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Steven Whitehouse <swhiteho@...hat.com>,
David Howells <dhowells@...hat.com>,
viro <viro@...iv.linux.org.uk>,
Christian Brauner <christian@...uner.io>,
Jann Horn <jannh@...gle.com>,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Linux API <linux-api@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
Lennart Poettering <lennart@...ttering.net>,
Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
util-linux@...r.kernel.org
Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17]
On Fri, Feb 28, 2020 at 1:43 AM Ian Kent <raven@...maw.net> wrote:
> > I'm not sure about sysfs/, you need somehow resolve namespaces, order
> > of the mount entries (which one is the last one), etc. IMHO translate
> > mountpoint path to sysfs/ path will be complicated.
>
> I wonder about that too, after all sysfs contains a tree of nodes
> from which the view is created unlike proc which translates kernel
> information directly based on what the process should see.
>
> We'll need to wait a bit and see what Miklos has in mind for mount
> table enumeration and nothing has been said about name spaces yet.
Adding Greg for sysfs knowledge.
As far as I understand the sysfs model is, basically:
- list of devices sorted by class and address
- with each class having a given set of attributes
Superblocks and mounts could get enumerated by a unique identifier.
mnt_id seems to be good for mounts, s_dev may or may not be good for
superblock, but s_id (as introduced in this patchset) could be used
instead.
As for namespaces, that's "just" an access control issue, AFAICS.
For example a task with a non-initial mount namespace should not have
access to attributes of mounts outside of its namespace. Checking
access to superblock attributes would be similar: scan the list of
mounts and only allow access if at least one mount would get access.
> While fsinfo() is not similar to proc it does handle name spaces
> in a sensible way via. file handles, a bit similar to the proc fs,
> and ordering is catered for in the fsinfo() enumeration in a natural
> way. Not sure how that would be handled using sysfs ...
I agree that the access control is much more straightforward with
fsinfo(2) and this may be the single biggest reason to introduce a new
syscall.
Let's see what others thing.
Thanks,
Miklos
Powered by blists - more mailing lists