0

After entering su when I prompted to enter a password:

user@debian:~$ su
Password:

I can't send SIGSTOP (ctrl+Z) from my keyboard (the same terminal) - nothing happens. So the only way to exit is to type some (right or wrong) password. Why can't I suspend su such a way?

UPD: It seems that ctrl+Z is queued. Thus when sending ctrl+Z - nothing happens, but then after typing Enter signal arrives and su becomes stopped. Still can't understand such behavior. Is this standard behavior for all Unix-like or just Linux?

z0lupka
  • 275
  • How do you send SIGSTOP and/or SIGKILL ? – schaiba Jan 24 '20 at 16:34
  • @schaiba ctrl+Z and ctrl+C - the only way I know to send signals from terminal to running (in this terminal) task. – z0lupka Jan 24 '20 at 16:37
  • 2
    ctrl-C is not SIGKILL. it's usually SIGINT. And any process can ignore SIGINT. – Andrew Henle Jan 24 '20 at 16:47
  • @AndrewHenle Indeed. But what about SIGSTOP through ctrl+Z? – z0lupka Jan 24 '20 at 16:49
  • 2
    su is a setuid program that runs as root. You do not have privileges to kill a process owned by another user, even if it's running inside your terminal window. See the kill(2) man page for a more technical explanation. – doneal24 Jan 24 '20 at 16:49
  • 2
    @z0lupka ctrl-Z is usually SIGSTSP - see https://unix.stackexchange.com/questions/362559/list-of-terminal-generated-signals-eg-ctrl-c-sigint – Andrew Henle Jan 24 '20 at 16:51
  • 1
    @doneal24 That can get a bit complex with setuid programs, as the effective and real uid's do give the uid that started the process some permissions. See https://superuser.com/questions/1059998/dont-allow-user-to-kill-program-started-as-another-user-using-setuid-bit for killing a process Read the RATIONALE section on the POSIX setuid() page for some background. – Andrew Henle Jan 24 '20 at 16:56
  • 1
    @AndrewHenle it appears you've got an all the details for an answer in your comment thread, are you going to turn it into an answer? – derobert Jan 24 '20 at 17:46

1 Answers1

1

Let's clear up some basic errors:

  1. The signal is not queued. Queueing is a specific thing when it comes to signals, and does not happen with this particular signal. The signal is masked.
  2. This particular signal is not SIGSTOP. The susp character causes the line discipline to send a SIGTSTP.

As with so many things that contradict the 1980s view of the login and su commands, the root of the behaviour here is PAM.

It's not su doing this. And it does not happen on operating systems other than those using the Linux PAM library. It does not happen on the BSDs using the OpenPAM library, for example.

It is the Linux PAM provided PAM module named pam_unix doing this. More specifically, it is the library-supplied default "conversation" function misc_conv(), called inside the pam_unix code, that is doing this. It specifically masks SIGTSTP whilst it is prompting for an item of input, ostensibly so that the library can clean up. This is why the signal is not delivered until the input has been entered.

OpenPAM supplies a pam_unix PAM module too. This calls the OpenPAM library-supplied default "conversation" function openpam_ttyconv(). That latter does not mask signals. No-one seems to have noticed that one can suspend su at the password prompt on FreeBSD et al. and the terminal will be left with echo turned off. This is possibly because the operating-system-supplied command-line shells on FreeBSD all have line editing libraries, which immediately re-adjust terminal settings when they take over to prompt for input and do their own echoing anyway.

Further reading

JdeBP
  • 68,745