Re: What do you think ?: How should pseundo terminals behave ...

On 9/26/06, Brandon S. Allbery KF8NH <allbery_at_ece.cmu.edu> wrote:
>
> On Sep 26, 2006, at 13:29 , Magnus Ringman wrote:
>
> > On 9/26/06, Brandon S. Allbery KF8NH <allbery_at_ece.cmu.edu> wrote:
> >>
> >> 3a) Hangup all processes attached to the client and switch them to
> >> some kind of "dead" inode (which could be a fixed entity since all
> >> operations on it except close() fail).  (Don't real ttys do this?)
> >
> > -1.
> > Yes and no.  ttys do that on an actual hangup (when a hardware hangup
> > happens), however PTYs are intended to allow emulating the full
> > terminal line semantics, including hangup.  Imo the case of "pty
> > master side disappearing" is equivalent to "backing device (hardware)
> > no longer exists", not "remote end hung up".
>
> I think that in many circumstances (and, as you note, implemented in
> other OSes), the correct behavior *is* to treat hangup as "backing
> device no longer exists" --- an older session should not leak into a
> newer one, it is a potential security hole and certainly a potential
> source of confusion.  And if hardware ttys do it, I should think
> virtual ones should also do so for consistency.

Methinks Sir has it the wrong way around!
Hangup on a hardware device -doesn't- void a program's access to the
device.  It just (optionally) sends the process a SIGHUP.  That is why
somebody (iirc, for SunOS < 5) invented vhangup(2) as a means for a
new session owner to insure it was the only process using the
terminal.

With ptys, we have a different problem, namely non-persistent
"hardware" (xterms, remote connections, "screen" sessions etc.) that
when they are instantiated are absolutely interested in (1) insuring
that the slave-side program is just the one intended, and (2) in some
cases, the ability to send terminal-flavored signals to the process
without voiding its file descriptor.

B