On Mon, Sep 18, 2023 at 07:36:39AM +0800, Ian Kent wrote: > > On 18/9/23 02:18, Sargun Dhillon wrote: > > On Wed, Sep 13, 2023 at 9:25 AM Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote: > > > Add a way to query attributes of a single mount instead of having to parse > > > the complete /proc/$PID/mountinfo, which might be huge. > > > > > > Lookup the mount by the old (32bit) or new (64bit) mount ID. If a mount > > > needs to be queried based on path, then statx(2) can be used to first query > > > the mount ID belonging to the path. > > > > > > Design is based on a suggestion by Linus: > > > > > > "So I'd suggest something that is very much like "statfsat()", which gets > > > a buffer and a length, and returns an extended "struct statfs" *AND* > > > just a string description at the end." > > > > > > The interface closely mimics that of statx. > > > > > > Handle ASCII attributes by appending after the end of the structure (as per > > > above suggestion). Allow querying multiple string attributes with > > > individual offset/length for each. String are nul terminated (termination > > > isn't counted in length). > > > > > > Mount options are also delimited with nul characters. Unlike proc, special > > > characters are not quoted. > > > > > Thank you for writing this patch. I wish that this had existed the many times > > I've written parsers for mounts files in my life. > > > > What do you think about exposing the locked flags, a la what happens > > on propagation of mount across user namespaces? > > Which flags do you mean? When you propagate mounts across mount+user namespaces a subset of (security sensitive) mount attributes become locked. This information is currently only available via internal flags but not in any way explicitly exposed to userspace. There's a proposal to extend mount_setattr(2) to explicitly allow locking flags but that would mean a new set of mount attr flags. So until the format of that is determined and settled this should be kept out of statmount().
