Skip to content

Commit aac9029

Browse files
sargunkees
authored andcommitted
Documentation: seccomp: Fix user notification documentation
The documentation had some previously incorrect information about how userspace notifications (and responses) were handled due to a change from a previously proposed patchset. Signed-off-by: Sargun Dhillon <[email protected]> Acked-by: Tycho Andersen <[email protected]> Acked-by: Christian Brauner <[email protected]> Signed-off-by: Kees Cook <[email protected]> Fixes: 6a21cc5 ("seccomp: add a return code to trap to userspace") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected]
1 parent d07f6ca commit aac9029

File tree

1 file changed

+8
-8
lines changed

1 file changed

+8
-8
lines changed

Documentation/userspace-api/seccomp_filter.rst

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -250,14 +250,14 @@ Users can read via ``ioctl(SECCOMP_IOCTL_NOTIF_RECV)`` (or ``poll()``) on a
250250
seccomp notification fd to receive a ``struct seccomp_notif``, which contains
251251
five members: the input length of the structure, a unique-per-filter ``id``,
252252
the ``pid`` of the task which triggered this request (which may be 0 if the
253-
task is in a pid ns not visible from the listener's pid namespace), a ``flags``
254-
member which for now only has ``SECCOMP_NOTIF_FLAG_SIGNALED``, representing
255-
whether or not the notification is a result of a non-fatal signal, and the
256-
``data`` passed to seccomp. Userspace can then make a decision based on this
257-
information about what to do, and ``ioctl(SECCOMP_IOCTL_NOTIF_SEND)`` a
258-
response, indicating what should be returned to userspace. The ``id`` member of
259-
``struct seccomp_notif_resp`` should be the same ``id`` as in ``struct
260-
seccomp_notif``.
253+
task is in a pid ns not visible from the listener's pid namespace). The
254+
notification also contains the ``data`` passed to seccomp, and a filters flag.
255+
The structure should be zeroed out prior to calling the ioctl.
256+
257+
Userspace can then make a decision based on this information about what to do,
258+
and ``ioctl(SECCOMP_IOCTL_NOTIF_SEND)`` a response, indicating what should be
259+
returned to userspace. The ``id`` member of ``struct seccomp_notif_resp`` should
260+
be the same ``id`` as in ``struct seccomp_notif``.
261261

262262
It is worth noting that ``struct seccomp_data`` contains the values of register
263263
arguments to the syscall, but does not contain pointers to memory. The task's

0 commit comments

Comments
 (0)