Re: FAN_OPEN_EXEC event and ignore mask

[Jan Kara <jack@suse.cz>]

On Thu 01-11-18 16:45:47, Amir Goldstein wrote:
> > >
> > > Man page should be revised to clarify the currently expected behavior:
> > > FAN_EVENT_ON_CHILD ...
> > >   The flag has no effect when marking mounts
> > > + or filesystems and has no effect when set in ignore mask
> > >
> > > Please include that change in your man page draft for new
> > > ignore mask interpretations.
> >
> > OK. I've updated the man pages to include the clarification around the
> > revised handling of ignore mask. These can be found here:
> >
> > https://github.com/matthewbobrowski/man-pages/commits/fanotify_ignore
> >
> > Wasn't overly confident about where I've placed the explanations, but I
> > felt that's where they fitted best. I was also thinking that we could have
> > an example of a compound event to illustrate the functionality further?
> >
> 
> I can see it clearly now - Jan was right all along -
> We cannot afford to add new constructs to this man page
> like "compound event" - it will just be too complicated to understand.
> 
> In early discussions, we spoke of two options:
> - Independent event (this haven't been well defined)
> - Informational flag (like IN_ISDIR), which is unprecedented in fanotify
> 
> Jan steered you towards the Independent event option, which I now
> completely agree with and so I also agree with Jan that interpretation
> of ignore mask should be "mask the event bit out".

Good, so we are on the same page here.

> On the question of whether execve() should generate two "separate"
> events OPEN and OPEN_EXEC or just one combined event
> OPEN | OPEN_EXEC, I am leaning towards one combined event
> (like you implemented). Non permission events can be merged, so
> user will not know the difference anyway.

Agreed.

> Permission events cannot
> be merged, but man page doesn't say anything about that.
> It might be worth dropping a note about OPEN_EXEC_PERM
> that it could be expected to appear together in the same permission
> event with OPEN_PERM and user response will apply to both.

Umm, I'd actually prefer if the OPEN_PERM and OPEN_EXEC_PERM events didn't
get merged. The overhead is just an additional call to fsnotify() to find
out one of the events is uninteresting (realistically, 99% of users will be
looking OPEN_PERM or OPEN_EXEC_PERM but not both) and it just keeps things
simple in the API. I understand that it may seem somewhat unexpected that
single file open will generate two different fsnotify permission events
(again 99% users won't observe this anyway) but if we start "merging"
permission events I think we open more space for confusion - like when
event arrives with some bits trimmed due to ignore mask masking bits out or
what not. What do you think Amir?

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR