On Wed, Jan 09, 2019 at 12:32:42PM +0100, Jan Kara wrote:
On Wed 09-01-19 08:50:33, Amir Goldstein wrote:
On Tue, Jan 8, 2019 at 10:11 PM Sasha Levin sashal@kernel.org wrote:
From: Matthew Bobrowski mbobrowski@mbobrowski.org
[ Upstream commit 2d10b23082a7eb8be508b3789f2e7250a88a5ddb ]
Modify fanotify_should_send_event() so that it now returns a mask for an 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 Reviewed-by: Amir Goldstein amir73il@gmail.com Signed-off-by: Jan Kara jack@suse.cz Signed-off-by: Sasha Levin sashal@kernel.org
I have no objection to applying this patch to 4.20, but FYI, it does not fix anything. Before introducing FAN_OPEN_EXEC in 5.0-rc1, this patch has no visible effect.
Yes, the patch is just a code refactoring useful for the FAN_OPEN_EXEC feature.
I don't mind if you apply it. It will make stable code closer to mainline, which is always a good thing IMO. And FWIW, I think that patch is quite trivial and low risk.
I don't think applying code refactoring to stable is a good idea. Every change has a risk of regression and this particular one brings users no benefit. So I'd prefer to drop this patch from stable queue.
No objections there, dropping it. Thank you.
-- Thanks, Sasha