From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 18:09:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 745FD16A403 for ; Tue, 26 Sep 2006 18:09:33 +0000 (UTC) (envelope-from bmr@google.com) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7F9043D7D for ; Tue, 26 Sep 2006 18:09:29 +0000 (GMT) (envelope-from bmr@google.com) Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id k8QI9Mv9013627 for ; Tue, 26 Sep 2006 11:09:22 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=MOxnNHLC9+4bkyUWX8eOEg7tTIuoK6AxGXNSdmGVoYF2rgAs7hTYr+Jh/w+vpxgtj DjtT/2p42hGVd7SJB6HGg== Received: from smtp-out2.google.com (fpr7.prod.google.com [10.253.18.7]) by zps78.corp.google.com with ESMTP id k8QCYhud020257 for ; Tue, 26 Sep 2006 11:09:19 -0700 Received: by smtp-out2.google.com with SMTP id 7so247525fpr for ; Tue, 26 Sep 2006 11:09:19 -0700 (PDT) Received: by 10.253.195.13 with SMTP id s13mr886322fpf; Tue, 26 Sep 2006 11:09:19 -0700 (PDT) Received: by 10.253.14.15 with HTTP; Tue, 26 Sep 2006 11:09:19 -0700 (PDT) Message-ID: <4f674ca50609261109s78a26d3dh1dd0a6dc8c112ca2@mail.google.com> Date: Tue, 26 Sep 2006 20:09:19 +0200 From: "Magnus Ringman" To: "Brandon S. Allbery KF8NH" In-Reply-To: <8EECEF0C-8C94-4A7C-862A-633F67D3D229@ece.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <8EECEF0C-8C94-4A7C-862A-633F67D3D229@ece.cmu.edu> Cc: current@freebsd.org Subject: Re: What do you think ?: How should pseundo terminals behave ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 18:09:33 -0000 On 9/26/06, Brandon S. Allbery KF8NH wrote: > > On Sep 26, 2006, at 13:29 , Magnus Ringman wrote: > > > On 9/26/06, Brandon S. Allbery KF8NH 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