linux-kernel - Re: [PATCH v4 0/3] fs: allow statmount to fetch the fs_subtype and sb

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: <CAJfpegt5_5z1qSefL-Y7HGo0_j6OZGTQfM74wG6N2Q__vB0DsQ@mail.gmail.com>
Date: Wed, 13 Nov 2024 16:49:52 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Jan Kara <jack@...e.cz>
Cc: Jeff Layton <jlayton@...nel.org>, Karel Zak <kzak@...hat.com>, 
	Christian Brauner <brauner@...nel.org>, 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>, 
	Lennart Poettering <lennart@...ttering.net>
Subject: Re: [PATCH v4 0/3] fs: allow statmount to fetch the fs_subtype and sb_source

On Wed, 13 Nov 2024 at 16:18, Jan Kara <jack@...e.cz> wrote:
>
> On Wed 13-11-24 08:45:06, Jeff Layton wrote:
> > On Wed, 2024-11-13 at 12:27 +0100, Karel Zak wrote:
> > > On Tue, Nov 12, 2024 at 02:39:21PM GMT, Christian Brauner wrote:
> > > Next on the wish list is a notification (a file descriptor that can be
> > > used in epoll) that returns a 64-bit ID when there is a change in the
> > > mount node. This will enable us to enhance systemd so that it does not
> > > have to read the entire mount table after every change.
> > >
> >
> > New fanotify events for mount table changes, perhaps?
>
> Now that I'm looking at it I'm not sure fanotify is a great fit for this
> usecase. A lot of fanotify functionality does not really work for virtual
> filesystems such as proc and hence we generally try to discourage use of
> fanotify for them. So just supporting one type of event (like FAN_MODIFY)
> on one file inside proc looks as rather inconsistent interface. But I
> vaguely remember we were discussing some kind of mount event, weren't we?
> Or was that for something else?

Yeah, if memory serves right what we agreed on was that placing a
watch on a mount would result in events being generated for
mount/umount/move_mount directly under that mount.  So this would not
be monitoring the entire namespace as poll on /proc/$$/mountinfo does.
IIRC Lennart said that this is okay and even desirable for systemd,
since it's only interested in a particular set of mounts.

Thanks,
Miklos