Bug in setting t_pgrp?

[Spencer W. Thomas]

In article <8289 at brl-tgr.ARPA> Greg McGary <lcc.gm at 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 at utah-cs.ARPA)
	"A sharp tongue is the only edge tool that grows keener with
	 constant use" - Washington Irving