Bug 6560 - login incorrectly handles some shells: dies on keyboard quit character
login incorrectly handles some shells: dies on keyboard quit character
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
6.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Erik Troan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-31 01:41 EST by Chris Siebenmann
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-06 13:35:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Siebenmann 1999-10-31 01:41:53 EST
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).
Comment 1 Geoff Reedy 1999-12-14 01:54:59 EST
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.
Comment 2 Chris Siebenmann 1999-12-14 01:59:59 EST
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.
Comment 3 Geoff Reedy 1999-12-14 02:22:59 EST
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.
Comment 4 Chris Siebenmann 1999-12-14 04:56:59 EST
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?
Comment 5 Erik Troan 2001-02-07 19:57:11 EST
This was horrible broken. Fixed in util-linux-2.10s-3, and patch forwarded to
maintainer.

Note You need to log in before you can comment on or make changes to this bug.