Re: "kill -STOP" as noticed in ksh93u+ gitlab

[Bart Schaefer <schaefer@brasslantern.com>]

On Tue, Feb 27, 2024 at 9:39 PM Stephane Chazelas <stephane@chazelas.org> wrote:
>
> 2024-02-27 18:04:34 -0800, Bart Schaefer:
> [...]
> > Changing the "kill" command doesn't (in zsh at least) affect the
> > "suspend" command.
[...]
> > % kill -STOP $$
> > kill: kill 605210 failed: operation not permitted
> > %
>
> I can't reproduce that on Ubuntu 22.04. The wording of that
> error suggests it's the system blocking the kill() with EPERM.

Sorry, I worded that badly.  I meant I actually DID change the kill
command.  I made the corresponding change as in the ksh93u+ diffs.
Posted without implying yet that it be used:

diff --git a/Src/jobs.c b/Src/jobs.c
index 118c5e61b..cfc783f46 100644
--- a/Src/jobs.c
+++ b/Src/jobs.c
@@ -2890,7 +2890,12 @@ bin_kill(char *nam, char **argv, UNUSED(Options
ops), UNUSED(int func))
            returnval++;
        } else {
            int pid = atoi(*argv);
-           if (
+           if (pid == mypid && islogin &&
+               (sig == SIGSTOP || sig == SIGTSTP)) {
+               zwarnnam("kill", "kill %s failed: %e", *argv, errno = EPERM);
+               returnval++;
+           } else if (
+
 #ifdef HAVE_SIGQUEUE
                use_sigqueue ? sigqueue(pid, sig, sigqueue_info) :
 #endif


> If we're blocking kill -s STOP $$, should we also block kill -s
> STOP 0 and kill -s STOP -1?

That's less likely than someone starting a subshell and forgetting
that $$ doesn't mean the PID of the subshell.  And if using 0 / -1 the
intention is to signal multiple processes.

I suppose zsh could signal_block() the signal it is about to pass to
kill(), but that seems like (ahem) overkill.