From owner-freebsd-current@FreeBSD.ORG Mon Oct 6 09:17:23 2003 Return-Path: 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 2650C16A4B3; Mon, 6 Oct 2003 09:17:23 -0700 (PDT) Received: from hexagon.stack.nl (hexagon.stack.nl [131.155.140.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC8B143FBF; Mon, 6 Oct 2003 09:17:18 -0700 (PDT) (envelope-from jilles@stack.nl) Received: from turtle.stack.nl (turtle.stack.nl [2001:610:1108:5010:2e0:81ff:fe22:51d8]) by hexagon.stack.nl (Postfix) with ESMTP id 0A32C1C60; Mon, 6 Oct 2003 18:17:18 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id CD9BC1CC56; Mon, 6 Oct 2003 18:17:04 +0200 (CEST) Date: Mon, 6 Oct 2003 18:17:04 +0200 From: Jilles Tjoelker To: Robert Watson Message-ID: <20031006161704.GA4809@stack.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: current@FreeBSD.org Subject: Re: ptmx, /dev/pts support for 5.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 06 Oct 2003 16:17:23 -0000 On Sun, Oct 05, 2003 at 09:25:53PM -0400, Robert Watson wrote: > Last week, I did a bit of experimentation to look at privilege issues in > the allocation of ptys on FreeBSD. Right now, to safely allocate a > pty/tty pair, you basically need privilege (otherwise you can't > chown/chmod the slave node). I took a look at some of the approaches used > by other systems (specifically Linux, Solaris) and implemented basic ptmx > support for FreeBSD: > http://www.watson.org/~robert/freebsd/pts/ > I took the existing tty_pty.c driver code and remunged most of the dev_t > and clone handling, as well as open/close of both master and slave. It's > far from perfect -- more of an experiment really, but it has some notable > benefits, including allowing programs like window, xterm, etc, to allocate > ptys safely without privilege (although utmp still requires privilege if > you're into that sort of thing). pts/ttys are also GC'd to reset > ownership/permissions/flags in a race-free manner. The current implementation could also be changed to make it safe. It relies on an (ugly) setuid root helper /usr/libexec/pt_chown to chown the slave device. A revoke() call on the slave should be added somewhere after that in grantpt(), or in unlockpt(). A problem is that forking may confuse SIGCHLD handlers. grantpt() in FreeBSD blocks SIGCHLD, but I don't know whether that's enough. POSIX.1-2001 says that calling grantpt() with a SIGCHLD handler produces undefined results. With openpty() programs may not expect that. By the way, in System V the slave device is locked (cannot be opened) when the master is opened. The unlockpt() call unlocks it, so it can be opened, giving the user program time to chown and chmod the slave device. So unlockpt() has little to do with STREAMS, and it should be said in the manpage that this functionality is handled differently (namely, revoke(2)) in FreeBSD, as the deeper purpose of avoiding the race condition is as relevant in FreeBSD as in System V. Jilles Tjoelker