From: Petr Skocik <pskocik@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Kees Cook <keescook@chromium.org>,
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: Sat, 12 Aug 2023 01:37:59 +0200 [thread overview]
Message-ID: <bbea3292-df02-4f6b-5ffa-9cfc9681facc@gmail.com> (raw)
In-Reply-To: <87pm3t2rvl.fsf@email.froward.int.ebiederm.org>
Thanks. I appreciate your patch and your researching of this.
I still think returning -EPERM for kill(-1,s) (unlike for kill(-pgrp,s),
where it *can* make sense) is nonsensical because of how POSIX specifies
kill(-1,sig) specifically ("sig shall be sent to all processes
(excluding an unspecified set of system processes) for which the process
has permission to send that signal"). But as I said, any error will do
for me, so I am still grateful for your patch.
(The way I see it, the POSIX-mentioned possible hiding of processes via
ESRCH is a completely different matter. In kill(-1,sig) specifically,
targets that would return -EPERM are excluded/hidden by virtue of the
definition of kill(-1,sig), which makes it different from other types of
kills for which there's no generic need to hide EPERMs (only optional
specific need, hence the paragraph in the POSIX spec on processes with a
different security label)).
Best regards, Petr Skocik
prev parent reply other threads:[~2023-08-11 23:38 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
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 ` Petr Skocik [this message]
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=bbea3292-df02-4f6b-5ffa-9cfc9681facc@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
Powered by JetHome