linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Bobrowski <mbobrowski@mbobrowski.org>
To: jack@suse.cz, amir73il@gmail.com
Cc: linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	sgrubb@redhat.com
Subject: [PATCH v4 2/3] fanotify: return only user requested event types in event mask
Date: Thu, 11 Oct 2018 21:42:41 +1100	[thread overview]
Message-ID: <fbc201560ae8f6db7575e8c3942eb223e28f1e2a.1539249092.git.mbobrowski@mbobrowski.org> (raw)
In-Reply-To: <cover.1539249092.git.mbobrowski@mbobrowski.org>

Modified fanotify_should_send_event() so that it now returns a mask for
a event that contains ONLY flags for the event types that have been
specifically requested by the user. Flags that may have been included
within the event mask, but have not been explicitly requested by the
user will not be present in the returned value.

As an example, given the situation where a user requests events of type
FAN_OPEN. Traditionally, the event mask returned within an event that
occurred on a filesystem object that has been marked for monitoring and is
opened, will only ever have the FAN_OPEN bit set. With the introduction of
the new flags like FAN_OPEN_EXEC, and perhaps any other future event
flags, there is a possibility of the returned event mask containing more
than a single bit set, despite having only requested the single event type.
Prior to these modifications performed to fanotify_should_send_event(), a
user would have received a bundled event mask containing flags FAN_OPEN
and FAN_OPEN_EXEC in the instance that a file was opened for execution via
execve(), for example. This means that a user would receive event types
in the returned event mask that have not been requested. This runs the
possibility of breaking existing systems and causing other unforeseen
issues.

To mitigate this possibility, fanotify_should_send_event() has been
modified to return the event mask containing ONLY event types explicitly
requested by the user. This means that we will NOT report events that the
user did no set a mask for, and we will NOT report events that the user
has set an ignore mask for.

The function name fanotify_should_send_event() has also been updated so
that it's more relevant to what it has been designed to do.

Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
---
 fs/notify/fanotify/fanotify.c | 46 ++++++++++++++++++++---------------
 1 file changed, 26 insertions(+), 20 deletions(-)

diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index b3e92302ed84..9da334d343b8 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -89,7 +89,13 @@ static int fanotify_get_response(struct fsnotify_group *group,
 	return ret;
 }
 
-static bool fanotify_should_send_event(struct fsnotify_iter_info *iter_info,
+/*
+ * This function returns a mask for a event that only contains the flags
+ * that have been specifically requested by the user. Flags that may have
+ * been included within the event mask, but have not been ecplicitly
+ * requested by the user, will not be present in the returned mask.
+ */
+static u32 fanotify_group_event_mask(struct fsnotify_iter_info *iter_info,
 				       u32 event_mask, const void *data,
 				       int data_type)
 {
@@ -101,21 +107,21 @@ static bool fanotify_should_send_event(struct fsnotify_iter_info *iter_info,
 	pr_debug("%s: report_mask=%x mask=%x data=%p data_type=%d\n",
 		 __func__, iter_info->report_mask, event_mask, data, data_type);
 
-	/* if we don't have enough info to send an event to userspace say no */
+	/* If we don't have enough info to send an event to userspace say no */
 	if (data_type != FSNOTIFY_EVENT_PATH)
-		return false;
+		return 0;
 
-	/* sorry, fanotify only gives a damn about files and dirs */
+	/* Sorry, fanotify only gives a damn about files and dirs */
 	if (!d_is_reg(path->dentry) &&
 	    !d_can_lookup(path->dentry))
-		return false;
+		return 0;
 
 	fsnotify_foreach_obj_type(type) {
 		if (!fsnotify_iter_should_report_type(iter_info, type))
 			continue;
 		mark = iter_info->marks[type];
 		/*
-		 * if the event is for a child and this inode doesn't care about
+		 * If the event is for a child and this inode doesn't care about
 		 * events on the child, don't send it!
 		 */
 		if (type == FSNOTIFY_OBJ_TYPE_INODE &&
@@ -129,13 +135,10 @@ static bool fanotify_should_send_event(struct fsnotify_iter_info *iter_info,
 
 	if (d_is_dir(path->dentry) &&
 	    !(marks_mask & FS_ISDIR & ~marks_ignored_mask))
-		return false;
-
-	if (event_mask & FANOTIFY_OUTGOING_EVENTS &
-	    marks_mask & ~marks_ignored_mask)
-		return true;
+		return 0;
 
-	return false;
+	return event_mask & FANOTIFY_OUTGOING_EVENTS & marks_mask &
+		~marks_ignored_mask;
 }
 
 struct fanotify_event_info *fanotify_alloc_event(struct fsnotify_group *group,
@@ -194,6 +197,7 @@ static int fanotify_handle_event(struct fsnotify_group *group,
 				 struct fsnotify_iter_info *iter_info)
 {
 	int ret = 0;
+	u32 event_mask = 0;
 	struct fanotify_event_info *event;
 	struct fsnotify_event *fsn_event;
 
@@ -211,13 +215,15 @@ static int fanotify_handle_event(struct fsnotify_group *group,
 
 	BUILD_BUG_ON(HWEIGHT32(ALL_FANOTIFY_EVENT_BITS) != 11);
 
-	if (!fanotify_should_send_event(iter_info, mask, data, data_type))
+	event_mask = fanotify_group_event_mask(iter_info, mask, data,
+						data_type);
+	if (!event_mask)
 		return 0;
 
 	pr_debug("%s: group=%p inode=%p mask=%x\n", __func__, group, inode,
-		 mask);
+		 event_mask);
 
-	if (fanotify_is_perm_event(mask)) {
+	if (fanotify_is_perm_event(event_mask)) {
 		/*
 		 * fsnotify_prepare_user_wait() fails if we race with mark
 		 * deletion.  Just let the operation pass in that case.
@@ -226,14 +232,14 @@ static int fanotify_handle_event(struct fsnotify_group *group,
 			return 0;
 	}
 
-	event = fanotify_alloc_event(group, inode, mask, data);
+	event = fanotify_alloc_event(group, inode, event_mask, data);
 	ret = -ENOMEM;
 	if (unlikely(!event)) {
 		/*
 		 * We don't queue overflow events for permission events as
 		 * there the access is denied and so no event is in fact lost.
 		 */
-		if (!fanotify_is_perm_event(mask))
+		if (!fanotify_is_perm_event(event_mask))
 			fsnotify_queue_overflow(group);
 		goto finish;
 	}
@@ -242,18 +248,18 @@ static int fanotify_handle_event(struct fsnotify_group *group,
 	ret = fsnotify_add_event(group, fsn_event, fanotify_merge);
 	if (ret) {
 		/* Permission events shouldn't be merged */
-		BUG_ON(ret == 1 && mask & FANOTIFY_PERM_EVENTS);
+		BUG_ON(ret == 1 && event_mask & FANOTIFY_PERM_EVENTS);
 		/* Our event wasn't used in the end. Free it. */
 		fsnotify_destroy_event(group, fsn_event);
 
 		ret = 0;
-	} else if (fanotify_is_perm_event(mask)) {
+	} else if (fanotify_is_perm_event(event_mask)) {
 		ret = fanotify_get_response(group, FANOTIFY_PE(fsn_event),
 					    iter_info);
 		fsnotify_destroy_event(group, fsn_event);
 	}
 finish:
-	if (fanotify_is_perm_event(mask))
+	if (fanotify_is_perm_event(event_mask))
 		fsnotify_finish_user_wait(iter_info);
 
 	return ret;
-- 
2.17.2

  parent reply	other threads:[~2018-10-11 18:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-11 10:42 [PATCH v4 0/3] fanotify: introduce new event types FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM Matthew Bobrowski
2018-10-11 10:42 ` [PATCH v4 1/3] fanotify: introduce new event type FAN_OPEN_EXEC Matthew Bobrowski
2018-10-16 11:58   ` Jan Kara
2018-10-17  6:30     ` Matthew Bobrowski
2018-10-11 10:42 ` Matthew Bobrowski [this message]
2018-10-11 11:03   ` [PATCH v4 2/3] fanotify: return only user requested event types in event mask Amir Goldstein
2018-10-16 11:52   ` Jan Kara
2018-10-17  6:30     ` Matthew Bobrowski
2018-10-11 10:43 ` [PATCH v4 3/3] fanotify: introduce new event type FAN_OPEN_EXEC_PERM Matthew Bobrowski
2018-10-16 12:04   ` Jan Kara
2018-10-17  6:33     ` Matthew Bobrowski
2018-10-17 11:23       ` Jan Kara
2018-10-11 11:02 ` [PATCH v4 0/3] fanotify: introduce new event types FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM 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=fbc201560ae8f6db7575e8c3942eb223e28f1e2a.1539249092.git.mbobrowski@mbobrowski.org \
    --to=mbobrowski@mbobrowski.org \
    --cc=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sgrubb@redhat.com \
    /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).