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
