From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763166AbdKRUEt (ORCPT ); Sat, 18 Nov 2017 15:04:49 -0500 Received: from mail-wm0-f54.google.com ([74.125.82.54]:39409 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1763125AbdKRUEj (ORCPT ); Sat, 18 Nov 2017 15:04:39 -0500 X-Google-Smtp-Source: AGs4zMazKR7OJOBa5ZqX0p+J0PhtcM/G3JhfAwC+9MZ50ZFQErArwO+TPXOWNVGzqCiIR+2rpe25xw== Cc: mtk.manpages@gmail.com, Tyler Hicks , linux-man , lkml To: Kees Cook From: "Michael Kerrisk (man-pages)" Subject: seccomp() SECCOMP_RET_KILL_PROCESS text for man page Message-ID: Date: Sat, 18 Nov 2017 21:04:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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/