From owner-freebsd-current  Sun May 31 11:40:20 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA27989
          for freebsd-current-outgoing; Sun, 31 May 1998 11:40:20 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27981
          for <current@FreeBSD.ORG>; Sun, 31 May 1998 11:40:15 -0700 (PDT)
          (envelope-from michaelh@cet.co.jp)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id SAA07297; Sun, 31 May 1998 18:36:36 GMT
Date: Mon, 1 Jun 1998 03:36:36 +0900 (JST)
From: Michael Hancock <michaelh@cet.co.jp>
To: Terry Lambert <tlambert@primenet.com>
cc: julian@whistle.com, phk@critter.freebsd.dk, current@FreeBSD.ORG
Subject: Re: I see one major problem with DEVFS...
In-Reply-To: <199805311005.DAA20689@usr04.primenet.com>
Message-ID: <Pine.SV4.3.95.980601033450.7241A-100000@parkplace.cet.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sun, 31 May 1998, Terry Lambert wrote:

> > > Just to get peace over the land again, I think you should implement
> > > it so that one can mknod a device again, but discard the dev_t,
> > > and use whatever DEVFS knows (better).
> 
> This is a security hole.
> 
> If a device is removed from a chroot environment, it should be impossible
> to recreate it.
> 
> The reasoning should be obvious.

Why not just control permissions on mknod?


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message