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
