"kill -STOP" as noticed in ksh93u+ gitlab

"kill -STOP" as noticed in ksh93u+ gitlab

[Bart Schaefer]

> The kill built-in command now correctly refuses to issue SIGSTOP to the shell's own process if the shell is a login shell.

Is this something we should consider for zsh?

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

[Stephane Chazelas]

2024-02-26 13:26:37 -0800, Bart Schaefer:
> > The kill built-in command now correctly refuses to issue SIGSTOP to the shell's own process if the shell is a login shell.
> 
> Is this something we should consider for zsh?

Commit log gives more info:

> commit 8cc9a13deb3b29e30849d6c6c1cd4a48c5d2eb53
> Author: Martijn Dekker <martijn@inlv.org>
> Date:   Sat Sep 16 01:17:13 2023 +0100
> 
>     job_kill(): fix bogus assumption that login shell has PPID 1
> 
>     Normally, suspending a login shell with SIGSTOP (e.g., kill -STOP
>     $$) will irrecoverably freeze the terminal session, so it is a good
>     idea to prohibit that.
> 
>     But job_kill() (called via the 'kill' built-in, b_kill()) assumes
>     that any login shell has a parent PID of 1, a.k.a. init. This may
>     have been valid on some systems back in the 1980s, but when people
>     started using graphical terminals (if not before), that assumption
>     became universally bogus.
> 
>     Some shells (at least yash) prohibit issuing SIGSTOP to self if
>     their process is the session leader. But even that doesn't always
>     hold. For instance, on macOS, the terminal creates a login(1)
>     process (the session leader), and the login shell is its child.
> 
>     So really the only thing we can reliably do is check for the
>     -l/--login/SH_LOGIN_SHELL shell option (as the 'suspend' built-in
>     already does; see 3ba4900e).

(also note that suspend used to be an alias to kill -STOP $$
(yes, without the quotes around the expansion) in ksh93).

So that's about extending an old (obsolete) behaviour to
graphical terminal emulators and only for macos which is the
only system that I've heard of where terminal emulators create a
login shell.

But, that seems wrong. It made sense in the 80s where if you
froze your login session, you would have no chance to recover
from it. But in the graphical emulator case, you could envisage
one wanting to suspend their shell (login or not) and resume it
later with a SIGCONT from another shell (in a different terminal
emulator or different ssh session...).

And doing that for login shells makes less sense than for
session leaders especially considering it's even easier now to
start a login shell with zsh --login or ARGV0=-zsh zsh.

I've not seen any other shell that does that.

-- 
Stephane

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

[Bart Schaefer]

On Mon, Feb 26, 2024 at 11:05 PM Stephane Chazelas
<stephane@chazelas.org> wrote:
>
> So that's about extending an old (obsolete) behaviour to
> graphical terminal emulators and only for macos which is the
> only system that I've heard of where terminal emulators create a
> login shell.

It may be that MacOS is the only one where the default is that way,
but I nearly always configure my terminal windows to create login
shells on every X11-ish desktop I use.  Further if the terminal is
running a remote shell that'll also be a login, and if you suspend a
remote shell it's rather more difficult to resume it (unless you're
using "screen" or remote tmux or something in which case you
disconnect rather than suspend the process).

> But, that seems wrong. It made sense in the 80s where if you
> froze your login session, you would have no chance to recover
> from it. But in the graphical emulator case, you could envisage
> one wanting to suspend their shell (login or not) and resume it
> later with a SIGCONT from another shell (in a different terminal
> emulator or different ssh session...).

Changing the "kill" command doesn't (in zsh at least) affect the
"suspend" command.

schaefer[592] Src/zsh -f -o login
% suspend
suspend: can't suspend login shell
% suspend -f

zsh: suspended  Src/zsh -f -o login
schaefer[593] fg
[1]  + continued  Src/zsh -f -o login
% kill -STOP $$
kill: kill 605210 failed: operation not permitted
%

I think this is more to prevent accidental stoppage?

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

[Stephane Chazelas]

2024-02-27 18:04:34 -0800, Bart Schaefer:
[...]
> Changing the "kill" command doesn't (in zsh at least) affect the
> "suspend" command.
> 
> schaefer[592] Src/zsh -f -o login
> % suspend
> suspend: can't suspend login shell
> % suspend -f
> 
> zsh: suspended  Src/zsh -f -o login
> schaefer[593] fg
> [1]  + continued  Src/zsh -f -o login
> % 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.

> I think this is more to prevent accidental stoppage?

I'm still of the opinion that "kill pid" is low level enough an
interface to kill() that it should not be interfered with, but
that's not a strong opinion by any measure.

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

-- 
Stephane

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

[Stephane Chazelas]

2024-02-28 05:39:34 +0000, Stephane Chazelas:
[...]
> If we're blocking kill -s STOP $$, should we also block kill -s
> STOP 0 and kill -s STOP -1?

ksh93u+m doesn't:

$ ARGV0=-sh ./arch/linux.i386-64/bin/ksh
$ suspend
-sh: suspend: cannot suspend a login shell
$ kill -STOP $$
kill: 8205: permission denied
$ kill -STOP 0
zsh: suspended (signal)  ARGV0=-sh ./arch/linux.i386-64/bin/ksh

(I've not tried -1).

-- 
Stephane

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

[Bart Schaefer]

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.