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

[Christian Brauner]

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.