On Fri, Feb 28, 2020 at 09:35:17AM +0100, Miklos Szeredi wrote: > 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 Close enough :) > 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. So what would the sysfs tree look like with this? > 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. sysfs does handle namespaces, look at how networking does this. But, it's not exactly the simplest thing to do so, so be careful with that as this is going to be essential for this type of work. thanks, greg k-h
