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.
- 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.
$ stty quit '^\'
$ cat >/dev/null # a random command to sit there
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
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