seccomp_unotify.2: Changes after feed back from Tycho Andersen

Reported-by: Tycho Andersen <tycho@tycho.pizza>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

diff --git a/man2/seccomp_unotify.2 b/man2/seccomp_unotify.2
index 5b1e80a2e5e68791ab053ef219729fc17109e9ab..0bc53ac6db435a2e5d2f6789326853632b8c8eed 100644 (file)
--- a/man2/seccomp_unotify.2
+++ b/man2/seccomp_unotify.2
@@ -99,9 +99,6 @@ over a UNIX domain socket connection between the two processes (using the
 .BR SCM_RIGHTS
 ancillary message type described in
 .BR unix (7)).
-Another possibility is that the supervisor might inherit
-the file descriptor via
-.BR fork (2).
 .\"-------------------------------------
 .IP 3.
 The supervisor process will receive notification events
@@ -168,12 +165,10 @@ The information in the notification can be used to discover the
 values of pointer arguments for the target process's system call.
 (This is something that can't be done from within a seccomp filter.)
 To do this (and assuming it has suitable permissions),
-the supervisor opens the corresponding
+One way in which the supervisor can do this is to open the corresponding
 .I /proc/[pid]/mem
-file, seeks to the memory location that corresponds
-to one of the pointer arguments whose value is supplied
-in the notification event,
-and reads bytes from that location.
+file and read bytes from the location that corresponds to one of
+the pointer arguments whose value is supplied in the notification event.
 .\" Tycho Andersen mentioned that there are alternatives to /proc/PID/mem,
 .\" such as ptrace() and /proc/PID/map_files
 (The supervisor must be careful to avoid
@@ -1316,3 +1311,6 @@ main(int argc, char *argv[])
 .SH SEE ALSO
 .BR ioctl (2),
 .BR seccomp (2)
+.PP
+A further example program can be found in the kernel source file
+.IR samples/seccomp/user-trap.c .