Date: Tue, 26 Sep 2006 13:33:24 -0400 From: "Brandon S. Allbery KF8NH" <allbery@ece.cmu.edu> To: "Magnus Ringman" <bmr@google.com> Cc: current@freebsd.org, Justin Hibbits <jrh29@alumni.cwru.edu> Subject: Re: What do you think ?: How should pseundo terminals behave ... Message-ID: <8EECEF0C-8C94-4A7C-862A-633F67D3D229@ece.cmu.edu> In-Reply-To: <4f674ca50609261029s76432971yfc15171a3e89cb72@mail.google.com> References: <20060926111452.J91466@godot.imp.ch> <0C4B0125-11AA-4BDB-A4E3-163A6194AB68@alumni.cwru.edu> <98FD6058-7220-48DB-AC24-F989FCB2AE11@ece.cmu.edu> <4f674ca50609261029s76432971yfc15171a3e89cb72@mail.google.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 26, 2006, at 13:29 , Magnus Ringman wrote: > On 9/26/06, Brandon S. Allbery KF8NH <allbery@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. -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8EECEF0C-8C94-4A7C-862A-633F67D3D229>