linux-kernel - Re: [PATCH] inotify: disallow watches on unsupported filesystems

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: <hg55e37tvfjnb76lvffuhnvozdwm4k6xuqq6nmvjgjaryjqmee@ppujm6t5y7ju>
Date: Tue, 4 Mar 2025 14:07:39 -0500
From: Seyediman Seyedarab <imandevel@...il.com>
To: Amir Goldstein <amir73il@...il.com>
Cc: jack@...e.cz, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-kernel-mentees@...ts.linux.dev
Subject: Re: [PATCH] inotify: disallow watches on unsupported filesystems

On 25/03/04 05:41PM, Amir Goldstein wrote:
> On Tue, Mar 4, 2025 at 5:05 PM Seyediman Seyedarab <imandevel@...il.com> wrote:
> >
> > On 25/03/04 12:57PM, Amir Goldstein wrote:
> > > On Tue, Mar 4, 2025 at 8:59 AM Seyediman Seyedarab <imandevel@...il.com> wrote:

> > I understand why it might seem like disallowing users from monitoring
> > these filesystems could break userspace in some way. BUT, programs
> > work incorrectly precisely because they do not receive any information
> > from the kernel, so in other words they are already broken. There is no
> > way for them to know if the fs is supported or not. I mean, even we are
> > not sure at the moment, then how would they know.
> 
> Programs not knowing is a problem that could be fixed with a new API
> or new init flag to fanotify/inotify.
> 
> Existing programs that would break due to this change is unacceptable.
> 

Maybe something like IN_DISALLOW_REMOTE could work for now, at least
until remote change notifications are properly implemented for those
specific filesystems? Later, if needed, it could evolve into a new API,
and the flag could become the default behavior when passed to that API.

> > As an example, 'Waybar' is a userspace program affected by this patch.
> > Since it relies on monitoring sysfs, it isn't working properly anyway.
> > This is also due to the issue mentioned earlier... inotify_add_watch()
> > returns without an error, so the developers haven't realized that
> > inotify isn't actually supported on sysfs. There are over five
> > discussions regarding this issue that you can find them here:
> > https://github.com/Alexays/Waybar/pull/3474
> >
> 
> You need to distinguish "inotify does not work"
> from "inotify does not notify on 'remote' changes"
> that is changes that happen on the network fs server or inside the
> kernel (in sysfs case) vs. changes that happen via vfs syscalls
> on the mounted fs, be it p9, cifs, sysfs.
> 
> There are several discussions about supporting "remote change"
> notifications for network filesystems - this is a more complex problem.
> 
> In any case, I believe performing operations on the mounted fs
> generated inotify events for all the fs that you listed and without
> a claim that nobody is using this facility we cannot regress this
> behavior without an opt-in from the application.

Understood. So this is what I should work on (correct me if anything
seems off):
1. Carefully list all filesystems where "remote" changes occur.
2. Introduce a flag like FS_DISALLOW_INOTIFY_REMOTE in fs_flags
   for these filesystems.
3. Provide an option for userspace, such as IN_DISALLOW_REMOTE,
   so applications can explicitly handle this behavior.
4. (Possibly later, if it makes sense) Introduce a new syscall where
   FS_DISALLOW_INOTIFY_REMOTE is the default behavior.

Regards,
Seyediman