From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 10:12:54 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CC0E16A41A for ; Thu, 14 Feb 2008 10:12:54 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 138E813C468 for ; Thu, 14 Feb 2008 10:12:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id ECC1517104; Thu, 14 Feb 2008 10:12:52 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m1EACqJA023697; Thu, 14 Feb 2008 10:12:52 GMT (envelope-from phk@critter.freebsd.dk) To: Ed Schouten From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 14 Feb 2008 11:08:40 +0100." <20080214100840.GQ1340@hoeg.nl> Date: Thu, 14 Feb 2008 10:12:52 +0000 Message-ID: <23696.1202983972@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD Arch Subject: Re: Proposal for redesigning the TTY layer 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: Thu, 14 Feb 2008 10:12:54 -0000 In message <20080214100840.GQ1340@hoeg.nl>, Ed Schouten writes: >> Move prison checks into devfs >> >> They do not belong in DEVFS, since that would require DEVFS to know >> far more about the device semantics if the individual drivers than >> it ever should. >> >> You can put it in the generic tty layer if you want, that would be >> emminently sensible, but DEVFS is the wrong place for it. > >The reason why I was thinking about this, was because devfs already >stores per-device credentials (see cdevsw's si_cred field). Say, we want >to expose other resources through devfs (/dev/shm/..., etc), we could >also prevent access from other prisons there as well. The problem is that you need to tie several cdevs together in a way devfs can see, pts%d to ptm%d and so on. That level of visibility into the device' internal workings is complex to provide in devfs, if nothing else for locking reasons, and it is trivial to implemented in the relevant device driver, where all of the tied devices are very likely have shared softc data structure and locking. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.