From: Matthew Bobrowski <mbobrowski@mbobrowski.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: FAN_OPEN_EXEC event and ignore mask
Date: Fri, 2 Nov 2018 22:36:38 +1100 [thread overview]
Message-ID: <20181102113636.GA19847@workstation.internal.lab> (raw)
In-Reply-To: <CAOQ4uxixi+8=wa-caTvpEwSN5QhjN=1ir13ifq=cm5i4Lr3zZg@mail.gmail.com>
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
next prev parent reply other threads:[~2018-11-02 20:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1540635951.git.mbobrowski@mbobrowski.org>
[not found] ` <6ffb239329a462a82f078b9a1e5e06255888b620.1540635951.git.mbobrowski@mbobrowski.org>
[not found] ` <CAOQ4uxhts4FX9YBRPOqUjh+vfgfnUT5wxfcPDbNV8itWXjw7uA@mail.gmail.com>
[not found] ` <20181028060133.GA8066@development.internal.lab>
[not found] ` <CAOQ4uxjyneJDZfjbRDiasA_YF6gj8_Nxoyh8MYZGYkjXFyfbtA@mail.gmail.com>
[not found] ` <20181028222358.GA3769@workstation>
[not found] ` <20181029134620.GF5988@quack2.suse.cz>
[not found] ` <CAOQ4uxg+6MOWLz6pP=S1P-XowF58BA7NvfYqdxTbusaE19QuyQ@mail.gmail.com>
[not found] ` <20181030002744.GA4214@workstation>
2018-10-30 9:17 ` FAN_OPEN_EXEC event and ignore mask Amir Goldstein
2018-10-31 10:39 ` Matthew Bobrowski
2018-11-01 14:45 ` Amir Goldstein
2018-11-02 11:36 ` Matthew Bobrowski [this message]
2018-11-02 12:26 ` Amir Goldstein
2018-11-02 12:50 ` Jan Kara
2018-11-02 13:43 ` Amir Goldstein
2018-11-05 8:40 ` Jan Kara
2018-11-03 0:34 ` Matthew Bobrowski
2018-11-05 8:41 ` Jan Kara
2018-11-05 9:06 ` Matthew Bobrowski
2018-11-05 12:27 ` Amir Goldstein
2018-11-05 12:37 ` Matthew Bobrowski
2018-11-06 13:08 ` Matthew Bobrowski
2018-11-06 13:45 ` Amir Goldstein
2018-11-06 13:47 ` Amir Goldstein
2018-11-06 20:40 ` Matthew Bobrowski
2018-11-06 21:15 ` Amir Goldstein
2018-11-06 22:23 ` Matthew Bobrowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181102113636.GA19847@workstation.internal.lab \
--to=mbobrowski@mbobrowski.org \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.