From owner-freebsd-arch@FreeBSD.ORG Sat Jan 6 19:32:24 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 010C016A412 for ; Sat, 6 Jan 2007 19:32:24 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from heave.ugcs.caltech.edu (heave.ugcs.caltech.edu [131.215.176.104]) by mx1.freebsd.org (Postfix) with ESMTP id E219113C471 for ; Sat, 6 Jan 2007 19:32:23 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: by heave.ugcs.caltech.edu (Postfix, from userid 3640) id 8A8508F482; Sat, 6 Jan 2007 11:14:01 -0800 (PST) Date: Sat, 6 Jan 2007 11:14:01 -0800 From: Jonathan Dama To: freebsd-arch@freebsd.org Message-ID: <20070106191401.GC8574@heave.ugcs.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: jd@ugcs.caltech.edu Cc: Ed Schouten Subject: [ed@fxq.nl: Request for PTY/devfs changes] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2007 19:32:24 -0000 I am forwarding this message that was posted to -current to -arch where hopefully it is unlikely to get lost in the noise. ----- Forwarded message from Ed Schouten ----- Hello everyone, A few days ago I started to toy around with FreeBSD 7.x and jails with unionfs. After a few hours I got to know the dreaded 'zombie jail' bug (PR kern/89528). I've been reading a lot of kernel source the last few days and I think I now understand a lot of existing problems in the current code. There are a couple of bugs in the FreeBSD kernel that aren't hard to cure, but will lead to a better PTY implementation: - Dev_clone event handlers cannot determine whether a LOOKUP or a CREATE is performed. When you create a small script that performs a stat() on /dev/ptyp0 to /dev/ptySv, you create a bunch of device nodes that aren't bound to a real pty controller (which leads to ucred 'leaks'). Only invoking the event handler when a CREATE is performed simplifies the entire pty design, because we could immediately construct the pty structure. The pts code also suffers from this bug. A simple stat() on /dev/ptmx causes a pts to be created. - Both the pty and pts source contain some small checks to make sure you can't open pty's from other jails. A downside of this approach is that you can see all the system's pty's in /dev. This is thus a small information leak. A nicer implementation that would even be more generic would be to add a flag to cdevsw's d_flags called D_PRISONOWNED. When this flag is set, lookup()'s and readdir()'s inside a jail don't return objects that don't have the same prison as the caller. open() should have a small check to disallow access outside the jail and when not root. PRIV_TTY_PRISON could then be renamed to PRIV_DEVFS_PRISON. When the D_PRISONOWNED flag is unset, make_dev_credv() should make sure cr_prison inside cdev's si_cred is unset to prevent prison leaks. When both changes are implemented, the pty/pts code itself could be changed to be a lot more simple. I would love to send in the patches, but I first like to hear your opinions on this subject. Are my findings correct? If not, why? -- Ed Schouten WWW: http://g-rave.nl/ ----- End forwarded message -----