linux-kernel - Re: [PATCH] fs: Do not check if there is a fsnotify watcher on pseudo inodes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOQ4uxhm+afWpnb4RFw8LkZ+ZJtnFxqR5HB8Uyj-c44CU9SSJg@mail.gmail.com>
Date:   Fri, 12 Jun 2020 23:34:16 +0300
From:   Amir Goldstein <amir73il@...il.com>
To:     Mel Gorman <mgorman@...hsingularity.net>
Cc:     Jan Kara <jack@...e.cz>, Alexander Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] fs: Do not check if there is a fsnotify watcher on pseudo inodes

> > > So maybe it would be better to list all users of alloc_file_pseudo()
> > > and say that they all should be opted out of fsnotify, without mentioning
> > > "internal mount"?
> > >
> >
> > The users are DMA buffers, CXL, aio, anon inodes, hugetlbfs, anonymous
> > pipes, shmem and sockets although not all of them necessary end up using
> > a VFS operation that triggers fsnotify.  Either way, I don't think it
> > makes sense (or even possible) to watch any of those with fanotify so
> > setting the flag seems reasonable.
> >
>
> I also think this seems reasonable, but the more accurate reason IMO
> is found in the comment for d_alloc_pseudo():
> "allocate a dentry (for lookup-less filesystems)..."
>
> > I updated the changelog and maybe this is clearer.
>
> I still find the use of "internal mount" terminology too vague.
> "lookup-less filesystems" would have been more accurate,

Only it is not really accurate for shmfs anf hugetlbfs, which are
not lookup-less, they just hand out un-lookable inodes.

> because as you correctly point out, the user API to set a watch
> requires that the marked object is looked up in the filesystem.
>
> There are also some kernel internal users that set watches
> like audit and nfsd, but I think they are also only interested in
> inodes that have a path at the time that the mark is setup.
>

FWIW I verified that watches can be set on anonymous pipes
via /proc/XX/fd, so if we are going to apply this patch, I think it
should be accompanied with a complimentary patch that forbids
setting up a mark on these sort of inodes. If someone out there
is doing this, at least they would get a loud message that something
has changed instead of silently dropping fsnotify events.

So now the question is how do we identify/classify "these sort of
inodes"? If they are no common well defining characteristics, we
may need to blacklist pipes sockets and anon inodes explicitly
with S_NONOTIFY.

Thanks,
Amir.