Greg McGary <lcc.gm@UCLA-LOCUS.ARPA> (02/13/85)
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@ucla-cs
{ucivax,trwb}!lcc!gm
{ihnp4,randvax,sdcrdcf,ucbvax,trwspp}!ucla-cs!lcc!gmthomas@utah-gr.UUCP (Spencer W. Thomas) (02/13/85)
In article <8289@brl-tgr.ARPA> Greg McGary <lcc.gm@UCLA-LOCUS.ARPA> writes: >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. You can also zero (or change) pgrp with the TIOCSPGRP ioctl call. This is, in fact, done by csh every time it puts a "job" in the foreground. I imagine that init also does it (although I haven't checked), or should. If you are running csh, it certainly isn't a problem, since csh has very definite ideas about the pgrp of itself and of the tty. Not so sure about sh. >... 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. Being a child of init is not sufficient, it is easy to write a program that makes itself an orphan, then opens the tty. With your scheme, it would then "take control" of the tty. Not good. The basic problem here is that Unix has no idea of a login session, which is what is needed to properly handle this problem. -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) "A sharp tongue is the only edge tool that grows keener with constant use" - Washington Irving