linux-kernel - Re: [PATCH 0/1] *** Fix kill(-1,s) returning 0 on 0 kills ***

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 12 Aug 2023 01:37:59 +0200
From:   Petr Skocik <pskocik@...il.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Kees Cook <keescook@...omium.org>, Oleg Nesterov <oleg@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Marco Elver <elver@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/1] *** Fix kill(-1,s) returning 0 on 0 kills ***

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