* seccomp() SECCOMP_RET_KILL_PROCESS text for man page
@ 2017-11-18 20:04 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 6+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-11-18 20:04 UTC (permalink / raw)
To: Kees Cook; +Cc: mtk.manpages, Tyler Hicks, linux-man, lkml
Hi Kees,
I came up with the following text (patch below) to describe the
SECCOMP_RET_KILL_PROCESS action that you added in 4.14. Does it
look okay?
SECCOMP_RET_KILL_PROCESS (since Linux 4.14)
This value results in immediate termination of the process,
with a core dump. The system call is not executed. By
contrast with SECCOMP_RET_KILL_THREAD below, all threads in
the thread group are terminated. (For a discussion of
thread groups, see the description of the CLONE_THREAD flag
in clone(2).)
The process terminates as though killed by a SIGSYS signal.
Even if a signal handler has been registered for SIGSYS,
the handler will be ignored in this case and the process
always terminates. To a parent process that is waiting on
this process (using waitpid(2) or similar), the returned
wstatus will indicate that its child was terminated as
though by a SIGSYS signal.
Cheers,
Michael
diff --git a/man2/seccomp.2 b/man2/seccomp.2
index 2e912940e..1b6bb2e51 100644
--- a/man2/seccomp.2
+++ b/man2/seccomp.2
@@ -399,6 +399,36 @@ returned by execution of all of the filters.
In decreasing order of precedence,
the values that may be returned by a seccomp filter are:
.TP
+.BR SECCOMP_RET_KILL_PROCESS " (since Linux 4.14)"
+.\" commit 4d3b0b05aae9ee9ce0970dc4cc0fb3fad5e85945
+.\" commit 0466bdb99e8744bc9befa8d62a317f0fd7fd7421
+This value results in immediate termination of the process,
+with a core dump.
+The system call is not executed.
+By contrast with
+.BR SECCOMP_RET_KILL_THREAD
+below, all threads in the thread group are terminated.
+(For a discussion of thread groups, see the description of the
+.BR CLONE_THREAD
+flag in
+.BR clone (2).)
+.IP
+The process terminates
+.I "as though"
+killed by a
+.B SIGSYS
+signal.
+Even if a signal handler has been registered for
+.BR SIGSYS ,
+the handler will be ignored in this case and the process always terminates.
+To a parent process that is waiting on this process (using
+.BR waitpid (2)
+or similar), the returned
+.I wstatus
+will indicate that its child was terminated as though by a
+.BR SIGSYS
+signal.
+.TP
.BR SECCOMP_RET_KILL_THREAD " (or " SECCOMP_RET_KILL )
This value results in immediate termination of the thread
that made the system call.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply related [flat|nested] 6+ messages in thread
* seccomp() SECCOMP_RET_KILL_PROCESS text for man page
@ 2017-11-18 20:04 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 6+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-11-18 20:04 UTC (permalink / raw)
To: Kees Cook
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Tyler Hicks, linux-man, lkml
Hi Kees,
I came up with the following text (patch below) to describe the
SECCOMP_RET_KILL_PROCESS action that you added in 4.14. Does it
look okay?
SECCOMP_RET_KILL_PROCESS (since Linux 4.14)
This value results in immediate termination of the process,
with a core dump. The system call is not executed. By
contrast with SECCOMP_RET_KILL_THREAD below, all threads in
the thread group are terminated. (For a discussion of
thread groups, see the description of the CLONE_THREAD flag
in clone(2).)
The process terminates as though killed by a SIGSYS signal.
Even if a signal handler has been registered for SIGSYS,
the handler will be ignored in this case and the process
always terminates. To a parent process that is waiting on
this process (using waitpid(2) or similar), the returned
wstatus will indicate that its child was terminated as
though by a SIGSYS signal.
Cheers,
Michael
diff --git a/man2/seccomp.2 b/man2/seccomp.2
index 2e912940e..1b6bb2e51 100644
--- a/man2/seccomp.2
+++ b/man2/seccomp.2
@@ -399,6 +399,36 @@ returned by execution of all of the filters.
In decreasing order of precedence,
the values that may be returned by a seccomp filter are:
.TP
+.BR SECCOMP_RET_KILL_PROCESS " (since Linux 4.14)"
+.\" commit 4d3b0b05aae9ee9ce0970dc4cc0fb3fad5e85945
+.\" commit 0466bdb99e8744bc9befa8d62a317f0fd7fd7421
+This value results in immediate termination of the process,
+with a core dump.
+The system call is not executed.
+By contrast with
+.BR SECCOMP_RET_KILL_THREAD
+below, all threads in the thread group are terminated.
+(For a discussion of thread groups, see the description of the
+.BR CLONE_THREAD
+flag in
+.BR clone (2).)
+.IP
+The process terminates
+.I "as though"
+killed by a
+.B SIGSYS
+signal.
+Even if a signal handler has been registered for
+.BR SIGSYS ,
+the handler will be ignored in this case and the process always terminates.
+To a parent process that is waiting on this process (using
+.BR waitpid (2)
+or similar), the returned
+.I wstatus
+will indicate that its child was terminated as though by a
+.BR SIGSYS
+signal.
+.TP
.BR SECCOMP_RET_KILL_THREAD " (or " SECCOMP_RET_KILL )
This value results in immediate termination of the thread
that made the system call.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: seccomp() SECCOMP_RET_KILL_PROCESS text for man page
@ 2017-11-18 20:52 ` Kees Cook
0 siblings, 0 replies; 6+ messages in thread
From: Kees Cook @ 2017-11-18 20:52 UTC (permalink / raw)
To: Michael Kerrisk (man-pages); +Cc: Tyler Hicks, linux-man, lkml
On Sat, Nov 18, 2017 at 12:04 PM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> Hi Kees,
>
> I came up with the following text (patch below) to describe the
> SECCOMP_RET_KILL_PROCESS action that you added in 4.14. Does it
> look okay?
>
> SECCOMP_RET_KILL_PROCESS (since Linux 4.14)
> This value results in immediate termination of the process,
> with a core dump. The system call is not executed. By
> contrast with SECCOMP_RET_KILL_THREAD below, all threads in
> the thread group are terminated. (For a discussion of
> thread groups, see the description of the CLONE_THREAD flag
> in clone(2).)
>
> The process terminates as though killed by a SIGSYS signal.
> Even if a signal handler has been registered for SIGSYS,
> the handler will be ignored in this case and the process
> always terminates. To a parent process that is waiting on
> this process (using waitpid(2) or similar), the returned
> wstatus will indicate that its child was terminated as
> though by a SIGSYS signal.
>
> Cheers,
>
> Michael
>
>
> diff --git a/man2/seccomp.2 b/man2/seccomp.2
> index 2e912940e..1b6bb2e51 100644
> --- a/man2/seccomp.2
> +++ b/man2/seccomp.2
> @@ -399,6 +399,36 @@ returned by execution of all of the filters.
> In decreasing order of precedence,
> the values that may be returned by a seccomp filter are:
> .TP
> +.BR SECCOMP_RET_KILL_PROCESS " (since Linux 4.14)"
> +.\" commit 4d3b0b05aae9ee9ce0970dc4cc0fb3fad5e85945
> +.\" commit 0466bdb99e8744bc9befa8d62a317f0fd7fd7421
> +This value results in immediate termination of the process,
> +with a core dump.
> +The system call is not executed.
> +By contrast with
> +.BR SECCOMP_RET_KILL_THREAD
> +below, all threads in the thread group are terminated.
> +(For a discussion of thread groups, see the description of the
> +.BR CLONE_THREAD
> +flag in
> +.BR clone (2).)
> +.IP
> +The process terminates
> +.I "as though"
> +killed by a
> +.B SIGSYS
> +signal.
> +Even if a signal handler has been registered for
> +.BR SIGSYS ,
> +the handler will be ignored in this case and the process always terminates.
> +To a parent process that is waiting on this process (using
> +.BR waitpid (2)
> +or similar), the returned
> +.I wstatus
> +will indicate that its child was terminated as though by a
> +.BR SIGSYS
> +signal.
> +.TP
> .BR SECCOMP_RET_KILL_THREAD " (or " SECCOMP_RET_KILL )
> This value results in immediate termination of the thread
> that made the system call.
This is perfect, thank you!
One thing to adjust elsewhere would be to rename SECCOMP_RET_ACTION to
SECCOMP_RET_ACTION_FULL (the new mask covers the bits used by
SECCOMP_RET_KILL_PROCESS).
-Kees
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: seccomp() SECCOMP_RET_KILL_PROCESS text for man page
@ 2017-11-18 20:52 ` Kees Cook
0 siblings, 0 replies; 6+ messages in thread
From: Kees Cook @ 2017-11-18 20:52 UTC (permalink / raw)
To: Michael Kerrisk (man-pages); +Cc: Tyler Hicks, linux-man, lkml
On Sat, Nov 18, 2017 at 12:04 PM, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Kees,
>
> I came up with the following text (patch below) to describe the
> SECCOMP_RET_KILL_PROCESS action that you added in 4.14. Does it
> look okay?
>
> SECCOMP_RET_KILL_PROCESS (since Linux 4.14)
> This value results in immediate termination of the process,
> with a core dump. The system call is not executed. By
> contrast with SECCOMP_RET_KILL_THREAD below, all threads in
> the thread group are terminated. (For a discussion of
> thread groups, see the description of the CLONE_THREAD flag
> in clone(2).)
>
> The process terminates as though killed by a SIGSYS signal.
> Even if a signal handler has been registered for SIGSYS,
> the handler will be ignored in this case and the process
> always terminates. To a parent process that is waiting on
> this process (using waitpid(2) or similar), the returned
> wstatus will indicate that its child was terminated as
> though by a SIGSYS signal.
>
> Cheers,
>
> Michael
>
>
> diff --git a/man2/seccomp.2 b/man2/seccomp.2
> index 2e912940e..1b6bb2e51 100644
> --- a/man2/seccomp.2
> +++ b/man2/seccomp.2
> @@ -399,6 +399,36 @@ returned by execution of all of the filters.
> In decreasing order of precedence,
> the values that may be returned by a seccomp filter are:
> .TP
> +.BR SECCOMP_RET_KILL_PROCESS " (since Linux 4.14)"
> +.\" commit 4d3b0b05aae9ee9ce0970dc4cc0fb3fad5e85945
> +.\" commit 0466bdb99e8744bc9befa8d62a317f0fd7fd7421
> +This value results in immediate termination of the process,
> +with a core dump.
> +The system call is not executed.
> +By contrast with
> +.BR SECCOMP_RET_KILL_THREAD
> +below, all threads in the thread group are terminated.
> +(For a discussion of thread groups, see the description of the
> +.BR CLONE_THREAD
> +flag in
> +.BR clone (2).)
> +.IP
> +The process terminates
> +.I "as though"
> +killed by a
> +.B SIGSYS
> +signal.
> +Even if a signal handler has been registered for
> +.BR SIGSYS ,
> +the handler will be ignored in this case and the process always terminates.
> +To a parent process that is waiting on this process (using
> +.BR waitpid (2)
> +or similar), the returned
> +.I wstatus
> +will indicate that its child was terminated as though by a
> +.BR SIGSYS
> +signal.
> +.TP
> .BR SECCOMP_RET_KILL_THREAD " (or " SECCOMP_RET_KILL )
> This value results in immediate termination of the thread
> that made the system call.
This is perfect, thank you!
One thing to adjust elsewhere would be to rename SECCOMP_RET_ACTION to
SECCOMP_RET_ACTION_FULL (the new mask covers the bits used by
SECCOMP_RET_KILL_PROCESS).
-Kees
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
--
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: seccomp() SECCOMP_RET_KILL_PROCESS text for man page
@ 2017-11-18 22:28 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 6+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-11-18 22:28 UTC (permalink / raw)
To: Kees Cook; +Cc: Tyler Hicks, linux-man, lkml
Hi Kees!
On 18 November 2017 at 21:52, Kees Cook <keescook@chromium.org> wrote:
> On Sat, Nov 18, 2017 at 12:04 PM, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>> Hi Kees,
>>
>> I came up with the following text (patch below) to describe the
>> SECCOMP_RET_KILL_PROCESS action that you added in 4.14. Does it
>> look okay?
>>
>> SECCOMP_RET_KILL_PROCESS (since Linux 4.14)
>> This value results in immediate termination of the process,
>> with a core dump. The system call is not executed. By
>> contrast with SECCOMP_RET_KILL_THREAD below, all threads in
>> the thread group are terminated. (For a discussion of
>> thread groups, see the description of the CLONE_THREAD flag
>> in clone(2).)
>>
>> The process terminates as though killed by a SIGSYS signal.
>> Even if a signal handler has been registered for SIGSYS,
>> the handler will be ignored in this case and the process
>> always terminates. To a parent process that is waiting on
>> this process (using waitpid(2) or similar), the returned
>> wstatus will indicate that its child was terminated as
>> though by a SIGSYS signal.
>>
>> Cheers,
>>
>> Michael
>>
>>
>> diff --git a/man2/seccomp.2 b/man2/seccomp.2
>> index 2e912940e..1b6bb2e51 100644
>> --- a/man2/seccomp.2
>> +++ b/man2/seccomp.2
>> @@ -399,6 +399,36 @@ returned by execution of all of the filters.
>> In decreasing order of precedence,
>> the values that may be returned by a seccomp filter are:
>> .TP
>> +.BR SECCOMP_RET_KILL_PROCESS " (since Linux 4.14)"
>> +.\" commit 4d3b0b05aae9ee9ce0970dc4cc0fb3fad5e85945
>> +.\" commit 0466bdb99e8744bc9befa8d62a317f0fd7fd7421
>> +This value results in immediate termination of the process,
>> +with a core dump.
>> +The system call is not executed.
>> +By contrast with
>> +.BR SECCOMP_RET_KILL_THREAD
>> +below, all threads in the thread group are terminated.
>> +(For a discussion of thread groups, see the description of the
>> +.BR CLONE_THREAD
>> +flag in
>> +.BR clone (2).)
>> +.IP
>> +The process terminates
>> +.I "as though"
>> +killed by a
>> +.B SIGSYS
>> +signal.
>> +Even if a signal handler has been registered for
>> +.BR SIGSYS ,
>> +the handler will be ignored in this case and the process always terminates.
>> +To a parent process that is waiting on this process (using
>> +.BR waitpid (2)
>> +or similar), the returned
>> +.I wstatus
>> +will indicate that its child was terminated as though by a
>> +.BR SIGSYS
>> +signal.
>> +.TP
>> .BR SECCOMP_RET_KILL_THREAD " (or " SECCOMP_RET_KILL )
>> This value results in immediate termination of the thread
>> that made the system call.
>
> This is perfect, thank you!
Good. Thanks for checking it.
> One thing to adjust elsewhere would be to rename SECCOMP_RET_ACTION to
> SECCOMP_RET_ACTION_FULL (the new mask covers the bits used by
> SECCOMP_RET_KILL_PROCESS).
Thanks. I missed that detail. I've made that change in the manual page.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: seccomp() SECCOMP_RET_KILL_PROCESS text for man page
@ 2017-11-18 22:28 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 6+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-11-18 22:28 UTC (permalink / raw)
To: Kees Cook; +Cc: Tyler Hicks, linux-man, lkml
Hi Kees!
On 18 November 2017 at 21:52, Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> On Sat, Nov 18, 2017 at 12:04 PM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Hi Kees,
>>
>> I came up with the following text (patch below) to describe the
>> SECCOMP_RET_KILL_PROCESS action that you added in 4.14. Does it
>> look okay?
>>
>> SECCOMP_RET_KILL_PROCESS (since Linux 4.14)
>> This value results in immediate termination of the process,
>> with a core dump. The system call is not executed. By
>> contrast with SECCOMP_RET_KILL_THREAD below, all threads in
>> the thread group are terminated. (For a discussion of
>> thread groups, see the description of the CLONE_THREAD flag
>> in clone(2).)
>>
>> The process terminates as though killed by a SIGSYS signal.
>> Even if a signal handler has been registered for SIGSYS,
>> the handler will be ignored in this case and the process
>> always terminates. To a parent process that is waiting on
>> this process (using waitpid(2) or similar), the returned
>> wstatus will indicate that its child was terminated as
>> though by a SIGSYS signal.
>>
>> Cheers,
>>
>> Michael
>>
>>
>> diff --git a/man2/seccomp.2 b/man2/seccomp.2
>> index 2e912940e..1b6bb2e51 100644
>> --- a/man2/seccomp.2
>> +++ b/man2/seccomp.2
>> @@ -399,6 +399,36 @@ returned by execution of all of the filters.
>> In decreasing order of precedence,
>> the values that may be returned by a seccomp filter are:
>> .TP
>> +.BR SECCOMP_RET_KILL_PROCESS " (since Linux 4.14)"
>> +.\" commit 4d3b0b05aae9ee9ce0970dc4cc0fb3fad5e85945
>> +.\" commit 0466bdb99e8744bc9befa8d62a317f0fd7fd7421
>> +This value results in immediate termination of the process,
>> +with a core dump.
>> +The system call is not executed.
>> +By contrast with
>> +.BR SECCOMP_RET_KILL_THREAD
>> +below, all threads in the thread group are terminated.
>> +(For a discussion of thread groups, see the description of the
>> +.BR CLONE_THREAD
>> +flag in
>> +.BR clone (2).)
>> +.IP
>> +The process terminates
>> +.I "as though"
>> +killed by a
>> +.B SIGSYS
>> +signal.
>> +Even if a signal handler has been registered for
>> +.BR SIGSYS ,
>> +the handler will be ignored in this case and the process always terminates.
>> +To a parent process that is waiting on this process (using
>> +.BR waitpid (2)
>> +or similar), the returned
>> +.I wstatus
>> +will indicate that its child was terminated as though by a
>> +.BR SIGSYS
>> +signal.
>> +.TP
>> .BR SECCOMP_RET_KILL_THREAD " (or " SECCOMP_RET_KILL )
>> This value results in immediate termination of the thread
>> that made the system call.
>
> This is perfect, thank you!
Good. Thanks for checking it.
> One thing to adjust elsewhere would be to rename SECCOMP_RET_ACTION to
> SECCOMP_RET_ACTION_FULL (the new mask covers the bits used by
> SECCOMP_RET_KILL_PROCESS).
Thanks. I missed that detail. I've made that change in the manual page.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-11-18 22:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-18 20:04 seccomp() SECCOMP_RET_KILL_PROCESS text for man page Michael Kerrisk (man-pages)
2017-11-18 20:04 ` Michael Kerrisk (man-pages)
2017-11-18 20:52 ` Kees Cook
2017-11-18 20:52 ` Kees Cook
2017-11-18 22:28 ` Michael Kerrisk (man-pages)
2017-11-18 22:28 ` Michael Kerrisk (man-pages)
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.