From: Michael Kerrisk Date: Wed, 30 Sep 2020 20:24:59 +0000 (+0200) Subject: seccomp_unotify.2: Changes after feed back from Tycho Andersen X-Git-Tag: man-pages-5.12~79 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=391194cd52f33e423c5ea02a89ff3841f4b8ecf6;p=thirdparty%2Fman-pages.git seccomp_unotify.2: Changes after feed back from Tycho Andersen Reported-by: Tycho Andersen Signed-off-by: Michael Kerrisk --- diff --git a/man2/seccomp_unotify.2 b/man2/seccomp_unotify.2 index 5b1e80a2e5..0bc53ac6db 100644 --- 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 .