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: <309c329dc3bab4ff8659fd7f1b48e7957aa32d80.camel@kernel.org>
Date: Tue, 12 Nov 2024 06:33:27 -0500
From: Jeff Layton <jlayton@...nel.org>
To: Christian Brauner <brauner@...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 Tue, 2024-11-12 at 10:42 +0100, Christian Brauner wrote:
> 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;

Ahh, I was trusting the manpage, which says:

       Note: glibc provides no wrapper for pidfd_open(), necessitating
the use of syscall(2).

It looks like recent glibc does have wrappers for this.
-- 
Jeff Layton <jlayton@...nel.org>