Re: FAN_OPEN_EXEC event and ignore mask

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 01, 2018 at 04:45:47PM +0200, 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".

Right, if that's the case then does that also mean that I can leave the
last two LTP test cases for FAN_OPEN_EXEC as they are? Based on the fact
that they've been defined to work with the ignore mask in that exact
manner?

Also, in addition to that, it means that the man-pages update that I've
linked above is completely irrelevant as we're in agreement that we're
not changing ignore mask behaviour?

> 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. 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.

Good point, I'll ensure to note this in my man-pages update for the EXEC
events.

-- 
Matthew Bobrowski



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux