Re: [PATCH 16/21] fsnotify: let a filesystem refuse marks on its objects

[Jan Kara]

On Fri 09-10-26 09:48:37, Christian Brauner wrote:
> On Mon, Oct 05, 2026 at 08:02:59AM +0200, Jan Kara wrote:
> > On Fri 02-10-26 16:26:19, Amir Goldstein wrote:
> > > On Fri, Oct 2, 2026 at 3:54 PM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> > > >
> > > > Don't let nullfs be watched. fanotify refuses mount and filesystem marks
> > > > on SB_NOUSER superblocks but inode marks of inotify, fanotify and
> > > > dnotify go through. The one inode of knullfs is the root of every
> > > > kernel thread and the following patches make it reachable from
> > > > userspace as the directory that stands in for an unmounted mount. A
> > > > watch placed through one such directory would report the opens through
> > > > all the others, across users.
> > > >
> > > > Add FS_DISALLOW_NOTIFY next to FS_DISALLOW_NOTIFY_PERM, refuse a mark on
> > > > any object of such a filesystem in fsnotify_add_mark_list() where every
> > > > backend ends up and set it for nullfs. There's nothing to watch on a
> > > > permanently empty and immutable filesystem.
> > > >
> > > 
> > > I don't particularly mind this custom opt-out, but
> > > shall we perhaps instead deny marks on SB_NOUSER directories?
> > > IIRC, we already wanted to deny marks on any SB_NOUSER, but then
> > > it turned out that some users set inotify watches on pipes, so we stepped
> > > back and restricted SB_NOUSER only for fs/mount marks.
> > > I think that the same logic extends well also for directories, because
> > > I don't think that any existing SB_NOUSER fs is supposed to be
> > > exposing them atm, so no regressions are to be expected.
> > 
> > Yes, I agree that placing marks on directories of SB_NOUSER filesystems
> > should be denied as well because it doesn't make sense which would settle
> > this case without a special flag AFAIU.
> 
> The problem is that we're introducing a file in another series which
> doesn't work with this option. My proposal would be that we do the flag
> now to get this fixed and then we follow-up with another more
> comprehensive approach.

OK, fair enough. Feel free to add:

Acked-by: Jan Kara <jack@xxxxxxx>

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR