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@xxxxxxxx> SUSE Labs, CR
