From: Petr Skocik <pskocik@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Oleg Nesterov <oleg@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Marco Elver <elver@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/1] *** Fix kill(-1,s) returning 0 on 0 kills ***
Date: Wed, 9 Aug 2023 14:27:27 +0200 [thread overview]
Message-ID: <d2d508b7-f267-0fe6-1b56-4292c95355a7@gmail.com> (raw)
In-Reply-To: <202211220913.AF86992@keescook>
Hi.
Is there anything else I can do to help get this (or some other
equivalent change that results in kill(-1,s) returning -ESRCH when it
has nothing to kill (like it does on the BSDs),
as opposed to the current return value of 0 in that case) incorporated
into mainline Linux?
It would rather help some of the user software I'm developing, and the
slightly new semantics are IMO definitely reasonable (BSDs have them).
Basically, the current code:
int retval = 0, count = 0;
struct task_struct * p;
for_each_process(p) {
if (task_pid_vnr(p) > 1 &&
!same_thread_group(p, current)) {
int err = group_send_sig_info(sig, info, p,
PIDTYPE_MAX);
++count;
if (err != -EPERM)
retval = err;
}
}
ret = count ? retval : -ESRCH;
counts kill attempts at non-1, other-process pids and sets hardcoded
-ESRCH only if no such attempts are made, which will almost never happen
for a nonroot EUID, because there will typically be non-pid-1 processes
unkillable by the nonroot EUID, but the code will still count those kill
attempts, and thus not return the hardcoded -ESRCH even if ALL of those
kill attemtpts return -EPERM, in which case -ESRCH would be in order
too, because there were no processes that the current EUID had
permission to kill (BDSs indeed return ESRCH in such a case).
(The kernel shouldn't need to concern itself with possible racy creation
of new EUID-killable processes during the kill(-1,s) walk. Either the
system can be known not to have running superuser code that could racily
create such EUID-killable processes and then such a kill-returned -ESRCH
would be useful, or it cannot be known not to have such running
superuser code, in which case the -ESRCH is transient and should be
droped by the user).
The current code also implicitly assumes either all non-EPERM kill
attempts return -EINVAL (invalid signal) or they
all return 0 (success). This assumption should be valid because either
the signal number is invalid and stays invalid, or it is valid and
the only possible error is -EPERM (this isn't sigqueue so the kill
shouldn't ever fail with -ENOMEM). If the assumption were not valid,
then the current code could overshadow a previous failed attempt with a
later succesful one, returning success even if there were some non-EPERM
failures.
My change proposes:
struct task_struct * p;
ret = -ESRCH;
for_each_process(p) {
if (task_pid_vnr(p) > 1 &&
!same_thread_group(p, current)) {
int err = group_send_sig_info(sig, info, p,
PIDTYPE_MAX);
if (err != -EPERM)
ret = err; /*either all 0 or all -EINVAL*/
}
}
i.e., start with -ESRCH (nothing to kill) and any non-EPERM kill
attempts change it to the last return value
--either all 0 or all -EINVAL as per the implicit assumption of the
original code.
It passes the tests put forth by Kees Cook.
More defensively, the implicit assumption of the original code could be
made explicit:
struct task_struct * p;
int has_last_err = 0;
ret = -ESRCH;
for_each_process(p) {
if (task_pid_vnr(p) > 1 &&
!same_thread_group(p, current)) {
int err = group_send_sig_info(sig, info, p,
PIDTYPE_MAX);
if (err != -EPERM){
if (has_last_err)
BUG_ON(ret != err); /*either all 0 or all -EINVAL*/
has_last_err = 1;
ret = err;
}
}
}
or dropped;
struct task_struct * p;
int has_last_err = 0;
ret = -ESRCH;
for_each_process(p) {
if (task_pid_vnr(p) > 1 &&
!same_thread_group(p, current)) {
int err = group_send_sig_info(sig, info, p,
PIDTYPE_MAX);
if (err != -EPERM){
if (has_last_err){
if (err >= 0)
continue; /*don't mask previous failure
with later success*/
}
has_last_err = 1;
ret = err;
}
}
}
Thanks again for consideration. Criticism welcome.
Regards,
Petr Skocik
On 11/22/22 18:15, Kees Cook wrote:
> On Tue, Nov 22, 2022 at 05:12:40PM +0100, Petr Skocik wrote:
>> Hi. I've never sent a kernel patch before but this one seemed trivial,
>> so I thought I'd give it a shot.
>>
>> My issue: kill(-1,s) on Linux doesn't return -ESCHR when it has nothing
>> to kill.
> It looks like LTP already tests for this, and gets -ESRCH?
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/containers/pidns/pidns10.c
>
> Does it still pass with your change?
>
next prev parent reply other threads:[~2023-08-09 12:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-22 16:12 Petr Skocik
2022-11-22 16:12 ` [PATCH 1/1] Fix kill(-1,s) returning 0 on 0 kills Petr Skocik
2022-11-23 10:30 ` Oleg Nesterov
2022-11-23 11:20 ` Oleg Nesterov
2022-11-23 11:27 ` Petr Skocik
2022-11-23 11:56 ` Oleg Nesterov
2022-11-22 17:15 ` [PATCH 0/1] *** Fix kill(-1,s) returning 0 on 0 kills *** Kees Cook
2022-11-22 23:01 ` Petr Skocik
2023-08-09 12:27 ` Petr Skocik [this message]
2023-08-10 16:16 ` Eric W. Biederman
2023-08-10 21:30 ` Petr Skocik
2023-08-11 21:25 ` Eric W. Biederman
2023-08-11 22:16 ` [PATCH] signal: Fix the error return of kill -1 Eric W. Biederman
2023-08-14 14:06 ` Oleg Nesterov
2023-08-14 15:43 ` Oleg Nesterov
2023-08-15 14:47 ` David Laight
2023-08-15 15:11 ` Oleg Nesterov
2023-08-16 20:32 ` Eric W. Biederman
2023-08-16 21:06 ` Oleg Nesterov
2023-08-17 2:33 ` Eric W. Biederman
2023-08-17 4:37 ` Eric W. Biederman
2023-08-17 15:47 ` [PATCH] __kill_pgrp_info: simplify the calculation of return value Oleg Nesterov
2023-08-11 23:37 ` [PATCH 0/1] *** Fix kill(-1,s) returning 0 on 0 kills *** Petr Skocik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d2d508b7-f267-0fe6-1b56-4292c95355a7@gmail.com \
--to=pskocik@gmail.com \
--cc=ebiederm@xmission.com \
--cc=elver@google.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®