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?
Let's clear up some basic errors:
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.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments