linux-kernel - Re: [PATCH v3 0/2] fs: allow statmount to fetch the subtype and devname

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <y3ijopq5e3zfdsyylmi7bf44otv2algem4mxprnres3x3mwnvl@2zcgj6y5j7rk>
Date: Tue, 12 Nov 2024 10:37:52 +0100
From: Karel Zak <kzak@...hat.com>
To: Jeff Layton <jlayton@...nel.org>
Cc: Christian Brauner <brauner@...nel.org>, 
	Miklos Szeredi <miklos@...redi.hu>, Ian Kent <raven@...maw.net>, Josef Bacik <josef@...icpanda.com>, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>
Subject: Re: [PATCH v3 0/2] fs: allow statmount to fetch the subtype and
 devname

On Mon, Nov 11, 2024 at 08:42:26AM GMT, Jeff Layton wrote:
> On Mon, 2024-11-11 at 10:17 +0100, Christian Brauner wrote:
> > On Thu, 07 Nov 2024 16:00:05 -0500, Jeff Layton wrote:
> > > Meta has some internal logging that scrapes /proc/self/mountinfo today.
> > > I'd like to convert it to use listmount()/statmount(), so we can do a
> > > better job of monitoring with containers. We're missing some fields
> > > though. This patchset adds them.
> > > 
> > > 
> > 
> > I know Karel has been wanting this for libmount as well. Thanks for
> > doing this! It would be nice if you could also add some selftests!
> > 
> 
> (cc'ing Karel)
> 
> Thanks. We may need to tweak this a bit, based on Miklos' comments
> about how empty strings are handled now, but it shouldn't be too big a
> change.
> 
> I actually have a related question about libmount: glibc doesn't
> currently provide syscall wrappers for statmount() and listmount().
> Would it make sense to have libmount provide those? We could copy the
> wrappers in tools/testing/selftests/filesystems/statmount/statmount.h
> to libmount.h.

I'm not sure if libmount is the right place. The library is complex
and large, and installing it just to get some simple wrappers seems
like overkill.

I believe the issue of "syscall wrappers" should be addressed in a
more generic manner, as the situation of wanting to try or use new
kernel features is quite common. This approach would also simplify
kernel testing.

> Another idea might be to start a new userland header file that is just
> a collection of static inline wrappers for syscalls that aren't
> packaged in glibc.e.g.  pidfd_open also doesn't have glibc bindings, so
> we could add that there too.

Yes, this seems like proper and portable solution. It would be great
if kernel itself will introduce any convention for this.

It's more syscalls without wrappers, sched_setattr, cachestat, kcmp, 
all pidfd_*, etc.

I'm not sure whether to create one collection of all syscalls or add
the wrappers to the appropriate locations (e.g. uapi/linux/mount.h
or introduce uapi/linux/mount_calls.h). The syscalls have dependencies
on specific structs such as 'struct statmount', etc.

    Karel

-- 
 Karel Zak  <kzak@...hat.com>
 http://karelzak.blogspot.com