Hello Matthew, On 1/12/19 2:56 AM, Matthew Bobrowski wrote: > New event masks have been added to the fanotify API. Documentation to > support the use and behaviour of these new masks has been added > accordingly. > > Signed-off-by: Matthew Bobrowski <mbobrowski@xxxxxxxxxxxxxx> > Reviewed-by: Amir Goldstein <amir73il@xxxxxxxxx> Thanks for the patch. I've applied, but I have a question below. > --- > man2/fanotify_mark.2 | 60 ++++++++++++++++++++++++++++++++++++++++++++ > man7/fanotify.7 | 18 +++++++++++++ > 2 files changed, 78 insertions(+) > > diff --git a/man2/fanotify_mark.2 b/man2/fanotify_mark.2 > index a9a482fe7..613c86cc4 100644 > --- a/man2/fanotify_mark.2 > +++ b/man2/fanotify_mark.2 > @@ -149,6 +149,12 @@ Create an event when a read-only file or directory is closed. > .B FAN_OPEN > Create an event when a file or directory is opened. > .TP > +.B FAN_OPEN_EXEC > +Create an event when a file is opened with the intent to be executed. > +See > +.B NOTES > +for additional details. > +.TP > .B FAN_Q_OVERFLOW > Create an event when an overflow of the event queue occurs. > The size of the event queue is limited to 16384 entries if > @@ -164,6 +170,18 @@ or > .B FAN_CLASS_CONTENT > is required. > .TP > +.B FAN_OPEN_EXEC_PERM > +Create an event when a permission to open a file for execution is > +requested. > +An fanotify file descriptor created with > +.B FAN_CLASS_PRE_CONTENT > +or > +.B FAN_CLASS_CONTENT > +is required. > +See > +.B NOTES > +for additional details. > +.TP > .B FAN_ACCESS_PERM > Create an event when a permission to read a file or directory is requested. > An fanotify file descriptor created with > @@ -309,6 +327,48 @@ was introduced in version 2.6.36 of the Linux kernel and enabled in version > 2.6.37. > .SH CONFORMING TO > This system call is Linux-specific. > +.SH NOTES > +When using either > +.B FAN_OPEN_EXEC > +or > +.B FAN_OPEN_EXEC_PERM > +within the > +.IR mask , > +events of these types will only be returned when the direct execution of a > +program occurs. > +More specifically, this means that events of these types shall be generated > +for files that are opened using system calls > +.BR execve(2) , > +.BR execveat(2) , > +or > +.BR uselib(2) . > +Events of these types will not be raised in the situation where an > +interpreter reads data as input and subsequently results in arbitrary > +computation. This last sentence is not so clear to me. Are you here talking about the situation where (say) awk(1) reads a script file and interprets its contents? > +.PP > +Additionally, if a mark has also been placed on the Linux dynamic > +linker/loader, a user should also expect to receive an event for it when > +an ELF object has been successfully opened using system calls > +.BR execve(2) > +or > +.BR execveat(2) . > +.PP > +For example, if the following ELF binary were to be invoked and a > +.BR FAN_OPEN_EXEC > +mark has been placed on /: > +.PP > +.EX > + ~> /bin/echo foo > +.EE > +.PP > +The listening application in this case will receive events > +.BR FAN_OPEN_EXEC > +for both the ELF binary and interpreter, respectively: > +.PP > +.EX > + /bin/echo > + /lib64/ld-linux-x86-64.so.2 > +.EE > .SH BUGS > The following bugs were present in Linux kernels before version 3.16: > .IP * 3 > diff --git a/man7/fanotify.7 b/man7/fanotify.7 > index 00e080522..cc2457735 100644 > --- a/man7/fanotify.7 > +++ b/man7/fanotify.7 > @@ -250,6 +250,14 @@ A file or a directory (but see BUGS) was accessed (read). > .B FAN_OPEN > A file or a directory was opened. > .TP > +.B FAN_OPEN_EXEC > +A file was opened with the intent to be executed. > +See > +.B NOTES > +in > +.BR fanotify_mark (2) > +for additional details. > +.TP > .B FAN_MODIFY > A file was modified. > .TP > @@ -285,6 +293,16 @@ access the filesystem object shall be granted. > An application wants to open a file or directory. > The reader must write a response that determines whether the permission to > open the filesystem object shall be granted. > +.TP > +.B FAN_OPEN_EXEC_PERM > +An application wants to open a file for execution. > +The reader must write a response that determines whether the permission to > +open the filesystem object for execution shall be granted. > +See > +.B NOTES > +in > +.BR fanotify_mark (2) > +for additional details. > .PP > To check for any close event, the following bit mask may be used: > .TP Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
