linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Bobrowski <mbobrowski@mbobrowski.org>
To: Jan Kara <jack@suse.cz>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Andy Lutomirski <luto@kernel.org>,
	Amir Goldstein <amir73il@gmail.com>,
	Linux API <linux-api@vger.kernel.org>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Steve Grubb <sgrubb@redhat.com>
Subject: Re: [PATCH v7 2/4] fanotify: introduce new event mask FAN_OPEN_EXEC
Date: Wed, 14 Nov 2018 10:26:01 +1100	[thread overview]
Message-ID: <20181113232559.GA3132@lithium.mbobrowski.org> (raw)
In-Reply-To: <20181113173503.GA12023@quack2.suse.cz>

On Tue, Nov 13, 2018 at 06:35:03PM +0100, Jan Kara wrote:
> > > >> OK.  You should probably add to your documentation that interpreters
> > > >> opened as a result of execve() and execveat() also set FAN_OPEN_EXEC.
> > > > 
> > > > I'm not sure I understand your concern (and thus need for documentation).
> > > > In the following I assume you watch the whole system for fanotify events
> > > > (you can restrict them to specific files / mount points / superblocks
> > > > but that's besides the point of this discussion).
> > > > If you do:
> > > > 
> > > > ~> /bin/echo
> > > > 
> > > > Then you get FAN_OPEN_EXEC event for '/bin/echo' file and nothing more.
> > > 
> > > If indeed that’s what the code does, then documenting it as such seems fine.
> > > But, by inspection, ELF interpreters are opened with open_exec(), so they
> > > should fire the event too. Am I wrong?
> > 
> > No, you're not wrong.
> > 
> > I do believe that there is no need to add a specific statement about
> > interpreters within the documentation.
> 
> So I think what Andy means is that if I watch / for FAN_OPEN_EXEC, then
> people may not immediately realize that if they do /bin/echo, they'll
> actually get events for
> 
> /bin/echo
> /lib64/ld-2.22.so
> 
> At least I didn't immediately realize that (and just compiled test kernel
> with your patches to verify). So I think this clarification would be worth
> it as a note in the manpage. Changelog can IMO stay as is.

OK, sure, I will add it.

-- 
Matthew Bobrowski

  reply	other threads:[~2018-11-14  9:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08  3:04 [PATCH v7 0/4] fanotify: introduce new event mask FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM Matthew Bobrowski
2018-11-08  3:05 ` [PATCH v7 1/4] fanotify: return only user requested event types in event mask Matthew Bobrowski
2018-11-13 17:38   ` Jan Kara
2018-11-13 17:53     ` Amir Goldstein
2018-11-13 23:54       ` Matthew Bobrowski
2018-11-14 12:04         ` Jan Kara
2018-11-08  3:07 ` [PATCH v7 2/4] fanotify: introduce new event mask FAN_OPEN_EXEC Matthew Bobrowski
2018-11-08 18:22   ` Andy Lutomirski
2018-11-09  5:41     ` Matthew Bobrowski
2018-11-09  6:04       ` Andy Lutomirski
2018-11-09  7:27         ` Matthew Bobrowski
2018-11-12 16:14         ` Jan Kara
2018-11-12 16:37           ` Andy Lutomirski
2018-11-13 11:45             ` Matthew Bobrowski
2018-11-13 17:35               ` Jan Kara
2018-11-13 23:26                 ` Matthew Bobrowski [this message]
2018-11-08  3:10 ` [PATCH v7 3/4] fsnotify: refactor fsnotify_parent()/fsnotify() paired calls when event is on path Matthew Bobrowski
2018-11-08  3:12 ` [PATCH v7 4/4] fanotify: introduce new event mask FAN_OPEN_EXEC_PERM Matthew Bobrowski
2018-11-13 17:53 ` [PATCH v7 0/4] fanotify: introduce new event mask FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM Jan Kara
2018-11-13 18:01   ` Amir Goldstein
2018-11-14  3:43     ` Amir Goldstein
2018-11-14 12:02       ` Jan Kara
2018-11-14 15:54         ` Amir Goldstein
2018-11-19 10:27         ` 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=20181113232559.GA3132@lithium.mbobrowski.org \
    --to=mbobrowski@mbobrowski.org \
    --cc=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=sgrubb@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).