Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17]
From: Miklos Szeredi
Date: Fri Feb 28 2020 - 03:35:31 EST
On Fri, Feb 28, 2020 at 1:43 AM Ian Kent <raven@xxxxxxxxxx> 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