From: Amir Goldstein <amir73il@gmail.com>
To: Seyediman Seyedarab <imandevel@gmail.com>
Cc: jack@suse.cz, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-kernel-mentees@lists.linux.dev
Subject: Re: [PATCH] inotify: disallow watches on unsupported filesystems
Date: Tue, 4 Mar 2025 12:57:36 +0100 [thread overview]
Message-ID: <CAOQ4uxiaY9cZFpj4m65SrAVXm7MqB2OFSfyH5D03hEwmdtiBVQ@mail.gmail.com> (raw)
In-Reply-To: <20250304080044.7623-1-ImanDevel@gmail.com>
On Tue, Mar 4, 2025 at 8:59 AM Seyediman Seyedarab <imandevel@gmail.com> wrote:
>
> currently, inotify_add_watch() allows adding watches on filesystems
> where inotify does not work correctly, without returning an explicit
> error. This behavior is misleading and can cause confusion for users
> expecting inotify to work on a certain filesystem.
That maybe so, but it's not that inotify does not work at all,
in fact it probably works most of the time for those fs,
so there may be users setting inotify watches on those fs,
so it is not right to regress those users.
>
> This patch explicitly rejects inotify usage on filesystems where it
> is known to be unreliable, such as sysfs, procfs, overlayfs, 9p, fuse,
> and others.
Where did you get this list of fs from?
Why do you claim that inotify does not work on overlayfs?
Specifically, there are two LTP tests inotify07 and inotify08
that test inotify over overlayfs.
This makes me question other fs on your list.
>
> By returning -EOPNOTSUPP, the limitation is made explicit, preventing
> users from making incorrect assumptions about inotify behavior.
>
> Signed-off-by: Seyediman Seyedarab <ImanDevel@gmail.com>
> ---
> fs/notify/inotify/inotify_user.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
> index b372fb2c56bd..9b96438f4d46 100644
> --- a/fs/notify/inotify/inotify_user.c
> +++ b/fs/notify/inotify/inotify_user.c
> @@ -87,6 +87,13 @@ static const struct ctl_table inotify_table[] = {
> },
> };
>
> +static const unsigned long unwatchable_fs[] = {
> + PROC_SUPER_MAGIC, SYSFS_MAGIC, TRACEFS_MAGIC,
> + DEBUGFS_MAGIC, CGROUP_SUPER_MAGIC, SECURITYFS_MAGIC,
> + RAMFS_MAGIC, DEVPTS_SUPER_MAGIC, BPF_FS_MAGIC,
> + OVERLAYFS_SUPER_MAGIC, FUSE_SUPER_MAGIC, NFS_SUPER_MAGIC
> +};
> +
> static void __init inotify_sysctls_init(void)
> {
> register_sysctl("fs/inotify", inotify_table);
> @@ -690,6 +697,14 @@ static struct fsnotify_group *inotify_new_group(unsigned int max_events)
> }
>
>
> +static inline bool is_unwatchable_fs(struct inode *inode)
> +{
> + for (int i = 0; i < ARRAY_SIZE(unwatchable_fs); i++)
> + if (inode->i_sb->s_magic == unwatchable_fs[i])
> + return true;
> + return false;
> +}
This is not a good practice for black listing fs.
See commit 0b3b094ac9a7b ("fanotify: Disallow permission events
for proc filesystem") for a better practice, but again, we cannot just
stop supporting inotify on fs where it was supported.
The assumption with the commit above was that setting permission
events on procfs is possible, but nobody (except for fuzzers) really does that
and if we have found out that there were actual users that do it, we
would have needed to revert that commit.
Thanks,
Amir.
next prev parent reply other threads:[~2025-03-04 11:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 8:00 [PATCH] inotify: disallow watches on unsupported filesystems Seyediman Seyedarab
2025-03-04 11:57 ` Amir Goldstein [this message]
2025-03-04 16:06 ` Seyediman Seyedarab
2025-03-04 16:41 ` Amir Goldstein
2025-03-04 19:07 ` Seyediman Seyedarab
2025-03-04 20:04 ` Amir Goldstein
2025-03-05 10:28 ` kernel test robot
2025-03-05 15:08 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOQ4uxiaY9cZFpj4m65SrAVXm7MqB2OFSfyH5D03hEwmdtiBVQ@mail.gmail.com \
--to=amir73il@gmail.com \
--cc=imandevel@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).