From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:50058 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730922AbeGSPnR (ORCPT ); Thu, 19 Jul 2018 11:43:17 -0400 From: Steve Grubb To: Jan Kara Cc: Matthew Bobrowski , amir73il@gmail.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] fanotify: introduce event flags FAN_EXEC and FAN_EXEC_PERM Date: Thu, 19 Jul 2018 10:59:42 -0400 Message-ID: <3769405.6YCAtSoBXm@x2> In-Reply-To: <20180719101708.ad754qhekwoyanps@quack2.suse.cz> References: <1531731011.19075.11.camel@mbobrowski.org> <1531912664.19075.19.camel@mbobrowski.org> <20180719101708.ad754qhekwoyanps@quack2.suse.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thursday, July 19, 2018 6:17:08 AM EDT Jan Kara wrote: > So fanotify is a filesystem event notification API. For filesystem, open > and read are fundamentally different events and as such we have different > FAN_OPEN and FAN_ACCESS events in the API. The only disputable events we > have in the API are FAN_CLOSE_WRITE vs FAN_CLOSE_NOWRITE - from fs POV > there's no big difference. But at least this is 100% reliably (unlike > FMODE_EXEC) telling you whether the user was able to modify the file or not > and it caters to one of the use cases this API has been created for - > virus scanners, file caching daemons, ... - i.e., triggering specific > actions based on file contents. Would it be more acceptable to not add FAN_EXEC_PERM on the front end where you ask for it at fanotify_mark. But rather add only FAN_EXEC? This would reduce the proposed API and just turn it into additional metadata about events that are already being requested. This ways you can do something like: mask = FAN_OPEN_PERM | FAN_EXEC; and then pass that to fanotify_mark. It would not affect old programs because they simply wouldn't ask for the bit. Would this be more palatable? Best Regards, -Steve