linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: "Ahelenia Ziemiańska" <nabijaczleweli@nabijaczleweli.xyz>,
	"Christian Brauner" <brauner@kernel.org>,
	"Al Viro" <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org
Subject: [RFC][PATCH] fanotify: disallow mount/sb marks on kernel internal pseudo fs
Date: Thu, 29 Jun 2023 07:20:44 +0300	[thread overview]
Message-ID: <20230629042044.25723-1-amir73il@gmail.com> (raw)

Hopefully, nobody is trying to abuse mount/sb marks for watching all
anonymous pipes/inodes.

I cannot think of a good reason to allow this - it looks like an
oversight that dated back to the original fanotify API.

Link: https://lore.kernel.org/linux-fsdevel/20230628101132.kvchg544mczxv2pm@quack3/
Fixes: d54f4fba889b ("fanotify: add API to attach/detach super block mark")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---

Jan,

As discussed, allowing sb/mount mark on anonymous pipes
makes no sense and we should not allow it.

I've noted FAN_MARK_FILESYSTEM as the Fixes commit as a trigger to
backport to maintained LTS kernels event though this dates back to day one
with FAN_MARK_MOUNT. Not sure if we should keep the Fixes tag or not.

The reason this is an RFC and that I have not included also the
optimization patch is because we may want to consider banning kernel
internal inodes from fanotify and/or inotify altogether.

The tricky point in banning anonymous pipes from inotify, which
could have existing users (?), but maybe not, so maybe this is
something that we need to try out.

I think we can easily get away with banning anonymous pipes from
fanotify altogeter, but I would not like to get to into a situation
where new applications will be written to rely on inotify for
functionaly that fanotify is never going to have.

Thoughts?
Am I over thinking this?

Amir.

 fs/notify/fanotify/fanotify_user.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index 95d7d8790bc3..8240a3fdbef0 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -1622,6 +1622,20 @@ static int fanotify_events_supported(struct fsnotify_group *group,
 	    path->mnt->mnt_sb->s_type->fs_flags & FS_DISALLOW_NOTIFY_PERM)
 		return -EINVAL;
 
+	/*
+	 * mount and sb marks are not allowed on kernel internal pseudo fs,
+	 * like pipe_mnt, because that would subscribe to events on all the
+	 * anonynous pipes in the system.
+	 *
+	 * XXX: SB_NOUSER covers all of the internal pseudo fs whose objects
+	 * are not exposed to user's mount namespace, but there are other
+	 * SB_KERNMOUNT fs, like nsfs, debugfs, for which the value of
+	 * allowing sb and mount mark is questionable.
+	 */
+	if (mark_type != FAN_MARK_INODE &&
+	    path->mnt->mnt_sb->s_flags & SB_NOUSER)
+		return -EINVAL;
+
 	/*
 	 * We shouldn't have allowed setting dirent events and the directory
 	 * flags FAN_ONDIR and FAN_EVENT_ON_CHILD in mask of non-dir inode,
-- 
2.34.1


             reply	other threads:[~2023-06-29  4:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-29  4:20 Amir Goldstein [this message]
2023-06-29 10:18 ` [RFC][PATCH] fanotify: disallow mount/sb marks on kernel internal pseudo fs Jan Kara
2023-06-29 12:20   ` Amir Goldstein
2023-06-29 12:51     ` Amir Goldstein
2023-06-29 13:49       ` Jan Kara
2023-06-30  7:29 ` Christian Brauner
2023-07-01 16:25   ` Amir Goldstein
2023-07-03  8:27     ` Christian Brauner
2023-07-03 11:25     ` Jan Kara
2023-07-04  9:58       ` Christian Brauner
2023-07-04 11:18         ` Jan Kara
2023-07-04 12:47           ` Christian Brauner
2023-07-04 13:19             ` Amir Goldstein

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=20230629042044.25723-1-amir73il@gmail.com \
    --to=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=nabijaczleweli@nabijaczleweli.xyz \
    --cc=viro@zeniv.linux.org.uk \
    /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).