> On Nov 12, 2018, at 8:14 AM, Jan Kara <jack@xxxxxxx> wrote: > >> On Thu 08-11-18 22:04:08, Andy Lutomirski wrote: >> On Thu, Nov 8, 2018 at 9:41 PM Matthew Bobrowski >> <mbobrowski@xxxxxxxxxxxxxx> wrote: >>> >>>> On Thu, Nov 08, 2018 at 10:22:50AM -0800, Andy Lutomirski wrote: >>>> On Wed, Nov 7, 2018 at 7:07 PM Matthew Bobrowski >>>> <mbobrowski@xxxxxxxxxxxxxx> wrote: >>>>> >>>>> A new event mask FAN_OPEN_EXEC has been defined so that users have the >>>>> ability to receive events specifically when a file has been opened with >>>>> the intent to be executed. Events of FAN_OPEN_EXEC type will be >>>>> generated when a file has been opened using either execve(), execveat() >>>>> or uselib() system calls. >>>>> >>>>> The feature is implemented within fsnotify_open() by generating the >>>>> FAN_OPEN_EXEC event type if __FMODE_EXEC is set within file->f_flags. >>>>> >>>> >>>> I think this needs some clarification. In particular: >>> >>> OK, sure. >>> >>>> Do current kernels generate some other fanotify on execve or do they >>>> generate no event at all? >>> >>> Yes, it does currently generate events on execve. Due to the nature of >>> how this particular system call works, the API, as is, will generate a >>> number of FAN_OPEN and FAN_ACCESS events. >>> >>>> What is the intended use case? >>> >>> For our particular use case, this is to greatly assist with an auditing >>> application that we're in the midst of developing. More specifically >>> though, it is to aid with providing additional context around why the >>> marked object(s) is being opened. We're interested to understand when >>> the direct execution of a file occurs via execve() or execveat(), for >>> example. This becomes exceptionally helpful on a busy filesystem when >>> you're trying to sift through and correlate FAN_OPEN and FAN_ACCESS >>> events while having marks placed on either a mount(s) or superblock(s). >> >> Seems reasonable. >> >>> >>>> What semantics do you provide for the opening of the ELF loader? Are >>>> those semantics useful? >>> >>> I don't exactly understand what you mean by providing semantics around >>> the opening of the ELF loader. However, I'm going to work with the >>> assumption that you're referring to how this particular event mask works >>> with the implicit invocation of the ELF loader when an ELF program is >>> being prepared for execution? If that's the case, it's quite simple. If >>> the ELF loader has been marked to receive events of this type, then an >>> event will also be generated for the ELF loader when an ELF program is >>> invoked via execve. If the ELF loader has not been marked, then only the >>> event for the ELF program itself will be generated. >> >> 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?
