fanotify_mark.2, fanotify.7: Minor tweaks to Matthew Bobrowski's patch

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

man2/fanotify_mark.2

@@ -149,11 +149,9 @@ 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
+.B FAN_OPEN_EXEC " (since Linux 5.0)"
 Create an event when a file is opened with the intent to be executed.
-See
-.B NOTES
-for additional details.
+See NOTES for additional details.
 .TP
 .B FAN_Q_OVERFLOW
 Create an event when an overflow of the event queue occurs.
@@ -170,7 +168,7 @@ or
 .B FAN_CLASS_CONTENT
 is required.
 .TP
-.B FAN_OPEN_EXEC_PERM
+.BR FAN_OPEN_EXEC_PERM " (since Linux 5.0)"
 Create an event when a permission to open a file for execution is
 requested.
 An fanotify file descriptor created with
@@ -178,9 +176,7 @@ An fanotify file descriptor created with
 or
 .B FAN_CLASS_CONTENT
 is required.
-See
-.B NOTES
-for additional details.
+See NOTES for additional details.
 .TP
 .B FAN_ACCESS_PERM
 Create an event when a permission to read a file or directory is requested.
@@ -328,47 +324,52 @@ was introduced in version 2.6.36 of the Linux kernel and enabled in version
 .SH CONFORMING TO
 This system call is Linux-specific.
 .SH NOTES
+.SS FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM
 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
+events of these types will be returned only 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) ,
+More specifically, this means that events of these types will be generated
+for files that are opened using
+.BR execve (2),
+.BR execveat (2),
 or
-.BR uselib(2) .
+.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.
 .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)
+linker, a user should also expect to receive an event for it when
+an ELF object has been successfully opened using
+.BR execve (2)
 or
-.BR execveat(2) .
+.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
+.in +4n
 .EX
-	~> /bin/echo foo
+$ /bin/echo foo
 .EE
+.in
 .PP
-The listening application in this case will receive events
+The listening application in this case would receive
 .BR FAN_OPEN_EXEC
-for both the ELF binary and interpreter, respectively:
+events for both the ELF binary and interpreter, respectively:
 .PP
+.in +4n
 .EX
-	/bin/echo
-	/lib64/ld-linux-x86-64.so.2
+/bin/echo
+/lib64/ld-linux-x86-64.so.2
 .EE
+.in
 .SH BUGS
 The following bugs were present in Linux kernels before version 3.16:
 .IP * 3

man7/fanotify.7

@@ -252,9 +252,7 @@ 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
+See NOTES in
 .BR fanotify_mark (2)
 for additional details.
 .TP
@@ -298,9 +296,7 @@ open the filesystem object shall be granted.
 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
+See NOTES in
 .BR fanotify_mark (2)
 for additional details.
 .PP