Hello folks.  Well, I've figured out the root cause of this problem,
but need suggestions on what we might do to fix it and keep it fixed.
Although I've included my previous messages on this topic below, I'll give
a brief summary of the problem here.
	If I launch the window program from a hardware terminal session, when
I exit the window program, the subshells it starts aren't sent a SIGHUP
signal, so they live on after window dies.  To make things worse, anyone
who opens the ptys these shells were living on after window goes away gets
immediate access to the sessions happening in those shells, as the original
user.  This problem is not manifested when the originating root terminal
session is on  a pty, i.e. when one telnets into a NetBSD box.

WHY THE PROBLEM OCCURS
	If the terminal on which the trouble occurs has clocal or mdmbuf set
in the cflags field of the tty structure, then those flags seem to be
inherited by any ptys that get opened by the window program.   When the
window program exits, ttymodem() gets called for each subptty and goes
through the following snippet of code:


			/*
			 * Lost carrier.
			 */
			CLR(tp->t_state, TS_CARR_ON);
			if (ISSET(tp->t_state, TS_ISOPEN) && !CONNECTED(tp)) {
				if (tp->t_session && tp->t_session->s_leader)
					psignal(tp->t_session->s_leader, SIGHUP);
[...]

	The "CONNECTED" macro is defined as:

#define	CONNECTED(tp)	(ISSET(tp->t_state, TS_CARR_ON) ||	\
			 ISSET(tp->t_cflag, CLOCAL | MDMBUF))

	As one can see, the SIGHUP is never sent to the process in the tty
structure because the tty is not "open and disconnected". 

	Now, I have a few questions about  how we might solve this dilemma.

1.  Where is the inheritance between the root terminal tty structure and
the pty substructures done?  I had some trouble finding it.

2.  does it even make sense for mdmbuf or clocal to be set on a pty?
Couldn't we just clear those bits unconditionally upon open and disable
them from being twiddled by stty?

	I'll try to cook up a patch that at least clears those bits on open
and close for ptys and send it along.  If I do, will someone pull it up
into 1.4?    Does anyone have any other suggestions that would be
cleaner/more elegant that would be appropriate for 1.4?

-Brian
On May 3, 11:05pm, Brian Buhrow wrote:
} Subject: Re: Problem with NetBSD 1.4_alpha with signals and persistent pro
} 	Hello Perry.  Well, I've played more with this problem and it seems to
} be worse than I originally thought.  Specifically, if I log into a NetBSD
} machine through a hardware serial connection, start the window program, shut
} it down, logout of the serial port, login as a different user on the same
} port, start the window program in that new session, I get access to all of
} the first user's shells under the window program.
} 	So, the problem seems to have to do with how access to the terminal
} gets revoked when the window process terminates.  Since it works fine on a
} pty, via telnet, and I can confirm that all of the proper signals are
} getting sent through the pty, I can only conclude that the sigHUP isn't
} getting sent to thetpgid of the terminal, or, that the child can't get
} signals off to the process groups it manages.  I'm trying to absorb the
} 4.4BSD book to understand what's going on here, but it's slow going.  In
} the interest of security, I'd like to point this out as a followup to
} pr/7499.  
} -Brian
} 
} 
} 
}                           NETBSD PROBLEM REPORT #7499
}                                        
} 
} Received: (qmail 29506 invoked from network); 29 Apr 1999 21:12:40 -0000
} Received: from rumpleteazer.ucsc.edu (HELO cats.ucsc.edu) (128.114.129.45)
}   by redmail.netbsd.org with SMTP; 29 Apr 1999 21:12:40 -0000
} Received: from baloo.ucsc.edu (baloo.UCSC.EDU [128.114.16.4])
}           by cats.ucsc.edu (8.8.6/8.8.4.cats-athena) with ESMTP
}           id OAA05116 for <gnats-bugs@gnats.netbsd.org>; Thu, 29 Apr 1999 14:12
} :41 -0700 (PDT)
} Received: (from buhrow@localhost)
}         by baloo.ucsc.edu (8.8.6/8.8.8.cats-client) id OAA06088
}         for gnats-bugs@gnats.netbsd.org; Thu, 29 Apr 1999 14:12:36 -0700 (PDT)
} Message-Id: <199904292112.OAA06088@baloo.ucsc.edu>
} Date: Thu, 29 Apr 1999 14:12:36 -0700 (PDT)
} From: buhrow@cats.ucsc.edu (Brian Buhrow)
} Reply-To: buhrow@cats.ucsc.edu
} To: gnats-bugs@gnats.netbsd.org
} Cc: buhrow@cats.ucsc.edu
} Subject: Problem with serial terminals and persistent children processes
} X-Send-Pr-Version: 3.95
} 
} 
} >Number:         7499
} >Category:       kern
} >Synopsis:       Subshells of the window program do not receive SIGHUP when win
} dow exits.
} >Confidential:   no
} >Severity:       serious
} >Priority:       high
} >Responsible:    kern-bug-people (Kernel Bug People)
} >State:          open
} >Class:          sw-bug
} >Submitter-Id:   net
} >Arrival-Date:   Thu Apr 29 14:20:00 1999
} >Originator:     Brian Buhrow
} >Organization:
}         UC Santa Cruz
} >Release:        NetBSD-current April 16, 1999
} >Environment:
} System: NetBSD glorfindel.nfbcal.org 1.4_ALPHA NetBSD 1.4_ALPHA (GLORFINDEL) #2
} : Fri Apr 16 12:13:16 PDT 1999 buhrow@glorfindel.nfbcal.org:/usr/src/sys/arch/i
} 386/compile/GLORFINDEL i386
} 
} 
} 
} 
} >Description:
}         <precise description of the problem (multiple lines)>
}         If the window program, shipped with the distribution, is invoked from
} a serial terminal session, i.e. through a hardware serial port, when the
} window program exits, the shells it spawned in the various windows, along
} with any processes they spawn, do not receive a SIGHUP signal.  They are
} supposed to receive a SIGHUP signal when window exits, and this does work
} when logging in through a telnet connection and a pseudo terminal.  As a
} result, the user of the window program leaves a bunch of orfaned processes
} on the system when he or she logs out unless he or she kills them manually
} by sending a SIGHUP with the kill(1) program.
}         This functionality worked in NetBSD 0.9, 1.0, 1.1 and 1.2, I haven't
} been able to test 1.3, but my suspicion is that it works there as well.
} I'm not sure where the problem is precisely, but I suspect that it is a
} problem with the interaction of the com driver and the tty layer.  The i386
} binary snapshot of March 15, 1999 shows the same behavior as the sources I
} used April 16, 1999.  The versions of the com and kern_tty files are as
} follows:
} /usr/src/sys/kern/tty.c:
}      $NetBSD: tty.c,v 1.112 1998/09/11 12:50:11 mycroft Exp $
} /usr/src/sys/dev/ic/com.c:
}      $NetBSD: com.c,v 1.159 1999/03/31 12:44:04 mrg Exp $
} 
} 
} >How-To-Repeat:
}         Activate a getty process on a serial port.
} 
} 
}         Use a terminal or terminal emulator to login through that serial port.
} (I don't know if kermit through two separate serial ports on the same
} computer would be a good test.)
} 
} 
}         Once you have a shell, install the enclosed .windowrc file in your
} home directory as  ~/.windowrc.
} 
} 
}         Launch the window program.
} %window -e^o
} 
} 
} Determine the process id for one of the shells in one of the windows that
} result.
} ^o3
} [3]%tty
} /dev/ttyp2
} ^o1
} [1]%ps -uxw |grep 'p2
} [1]%cd /var/tmp
} [1]%ktrace -p [pid found above]
} [1]%ls -l ktrace.out
} -rw------ 1 [user] 50 Apr 28 15:50 ktrace.out
} [1]%
} ^oq [Really quit? [yn]: y]
} %cd /var/tmp
} 
} 
} %ls -l ktrace.out
} -rw------ 1 [user] 50 Apr 28 15:50 ktrace.out
} 
} 
}         If the size of the file is unchanged, then the shell is still running
} and has not received its SIGHUP signal.  Otherwise, it will be about 495
} bytes or so and will have exited.  The ^o syntax above indicates a command
} to the window program itself and means issue a control-o.  The brackets
} indicate which window you're working in.  The non-bracketed prompts
} indicate you're working in the raw tty session.
}         Here is the .windowrc file I use and have used since window ran on
} Vaxen under 4.3BSD.
} 
} 
} nline 1000
} window(1,0,11,80)
} window(13,0,11,80)
} window(1,0,11,80)
} window(13,0,11,80)
} window(1,0,11,80)
} window(13,0,11,80)
} window(1,0,11,80)
} window(13,0,11,80)
} window(1,0,23,80)
} select 1
} 
} 
} >Fix:
}         I don't know how to work around this problem at this time.
} >Audit-Trail:
} >Unformatted:
} 
} 
} >Last-Modified:
} 
} 
}    
}      _________________________________________________________________
}    
}    NetBSD Problem Database Query Form
}      _________________________________________________________________
}    
}    NetBSD Home Page
}      _________________________________________________________________
}    
}    
}     www@NetBSD.ORG
}     $NetBSD: query-full-pr,v 1.19 1998/07/18 05:53:54 mycroft Exp $
}     $NetBSD: gnats_config.sh,v 1.4 1996/06/14 19:52:34 thorpej Exp $
}     Copyright (c) 1996 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
} 
>-- End of excerpt from Brian Buhrow