Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
Reply-To: mtk.manpages@gmail.com
In-Reply-To: <CAGXu5jKz_v3pEK3OsRBqxwJMHpgTJi=WE_3_GXgkZ-HnQ5RY0A@mail.gmail.com>
References: <a11b9a7a-1411-34d7-71aa-a29609729f21@gmail.com> <CAGXu5jKz_v3pEK3OsRBqxwJMHpgTJi=WE_3_GXgkZ-HnQ5RY0A@mail.gmail.com>
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Date:   Sat, 18 Nov 2017 23:28:31 +0100
Message-ID: <CAKgNAkj2Gdx64Wom333+w6S5XCvtpgXyACp0uKTM0h3okj4Otw@mail.gmail.com>
Subject: Re: seccomp() SECCOMP_RET_KILL_PROCESS text for man page
To:     Kees Cook <keescook@chromium.org>
Cc:     Tyler Hicks <tyhicks@canonical.com>,
        linux-man <linux-man@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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/

From 1584466847547702062@xxx Sun Nov 19 04:22:17 +0000 2017
X-GM-THRID: 1584466720357786746
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread