Bug in setting t_pgrp?

[Greg McGary]

In the 4.xBSD tty driver:

The line-discipline open sets `t_pgrp' to the pid of the process doing
the open only if `t_pgrp' was previously zero.

The line-discipline close is the only place `t_pgrp' is zeroed.
It is called out of the device close which gets called only on the final
close of the tty device.

With the job-control csh, background process(es) are
normally allowed to continue running when a person logs out.  With
non-job shells, it is possible for bg processes to continue running
after logout via nohup(1).  The bg process(es) may have inherited the
open tty from the shell, so when the shell exits and closes the tty,
this is not a final close. Thus no device close, thus no
line-discipline close, thus `t_pgrp' retains the pgrp of the dead
shell.  The next person who logs in on that terminal will have their
shell and controlling-tty placed in the pgrp of that dead shell.
Somewhere down the line, the pid of the dead shell will be reused.  If
the process that reuses this pid happens to be a pgrp leader, and that
`next person' mentioned above is still logged in, they can literally
have their signals crossed.

Granted, chances are pretty slim that this precise set of circumstances
will arise.  The thing I'm really puzzled about is the tty open code
that allows the non-zero `t_pgrp' to live on.  All of the code that
messes with controlling-tty linkages sits inside an if-statement that
is supposed to determine if the process doing the open is a child of
init(8).  It seems to me that being a child of init is enough
qualification for claiming the tty as the control terminal.  It seems
clearly *wrong* to perpetrate the pgrp of a probably dead process.

Does anyone know why the test for a zero `t_pgrp' is in the tty
line-discipline open code?

Greg McGary
Locus Computing Corporation				      lcc!gm at ucla-cs
						{ucivax,trwb}!lcc!gm
		{ihnp4,randvax,sdcrdcf,ucbvax,trwspp}!ucla-cs!lcc!gm