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: <20241112-vielzahl-grasen-51280e378f23@brauner>
Date: Tue, 12 Nov 2024 10:42:02 +0100
From: Christian Brauner <brauner@...nel.org>
To: Jeff Layton <jlayton@...nel.org>
Cc: Karel Zak <kzak@...hat.com>, 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 -0500, 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().

I think it'll be a bit until glibc exposes those system calls because I
think they are special-purpose in a lot of ways. But also because glibc
usually takes a while to add new system call wrappers.

> Would it make sense to have libmount provide those? We could copy the

I think libmount may not necessarily provide direct syscall wrappers but
will expose new api functionality. This is at least what I gather from
all the discussions on util-linux.

> wrappers in tools/testing/selftests/filesystems/statmount/statmount.h
> to libmount.h.
> 
> It's error-prone and a pain to roll these yourself, and that would make

As with most system calls.

> things simpler until someone is ready to do something for glibc.
> 
> 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.

Oh? What glibc version are you on? pidfd_open() et al should all have
glibc wrappers afaik. It just always takes a while:

        > cat /usr/include/x86_64-linux-gnu/sys/pidfd.h | grep pidfd
        extern int pidfd_open (__pid_t __pid, unsigned int __flags) __THROW;
        extern int pidfd_getfd (int __pidfd, int __targetfd,
        extern int pidfd_send_signal (int __pidfd, int __sig, siginfo_t *__info,
        extern pid_t pidfd_getpid (int __fd) __THROW;