Hide Forgot
If your login shell is a shell that does not put itself into a new process group, such as /bin/ash, using your quit character (often control-\) to abort a program and make it dump core will instead log you out, via causing login itself to get a SIGQUIT and die. Repeat by: - create a user that has /bin/ash as their login shell. - log into that user with a method that leaves a 'parent' login process running: on a text console will do, as will telnet'ing to localhost. - do: $ stty quit '^\' $ cat >/dev/null # a random command to sit there [type ^\] and watch the session get logged out, instead of just cat dumping core. One can clearly see login itself getting the SIGQUIT if you trace it (as root). Login needs to either put the child into a new process group, so that tty-caused signals will go only to that process group and not to login itself, or to SIG_IGN the signals for itself (but not for children). This is not a bug specific to /bin/ash; it's just that that /bin/ash is the only shell that Redhat itself ships that is simple enough to trigger this bug. It triggers with other shells, such as rc (and probably es).
I think this is actually the correct behavior. It is the shell that should deal with process group, not the login program. Since ash does not have any job control it does not set up a process group. The QUIT character raises SIGQUIT in all processes in the forground job. Again, since ash has no job control it is also sent the SIGQUIT. The real solution for this is for ash to trap SIGQUIT.
Ash trapping SIGQUIT itself would not help; see the log report. Login itself is failing to isolate itself from tty signals; no amount of signal catching or ignoring by the shell will help with this.
Regardless, login should not create a new process group, that is the shell's responsibility. So it would be a matter of login needing to handle certain signals, not creating process groups. Login does trap other singals that come fom the tty, so it should probably trap SIGQUIT also.
Login needs to thoroughly isolate itself from tty-based signals coming from the underlying terminal. SIGQUIT is only one example; there are a succession of other perverse ones (the tty-based job control ones, for example; I suspect that login is not currently shielded from them). The simplest way for this is for the persistent login process to use process groups to isolate itself from the tty; this is the traditional (and simple, and 100% complete) approach. Note further that there are ways of sending signals to all processes in your process group. Again, are people 100% sure that malicious people cannot do damage this way, since with the current approach one can send such signals to the login process?
This was horrible broken. Fixed in util-linux-2.10s-3, and patch forwarded to maintainer.