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>
This commit is contained in:
Michael Kerrisk 2020-09-30 22:24:59 +02:00
parent a9a8e35644
commit 391194cd52
1 changed files with 6 additions and 8 deletions

View File

@ -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 .