From owner-freebsd-current Sun May 31 05:14:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA17513 for freebsd-current-outgoing; Sun, 31 May 1998 05:14:10 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from critter.freebsd.dk ([195.8.133.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA17482 for ; Sun, 31 May 1998 05:14:05 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.5) with ESMTP id OAA03356; Sun, 31 May 1998 14:12:13 +0200 (CEST) To: Terry Lambert cc: julian@whistle.com, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-reply-to: Your message of "Sun, 31 May 1998 10:05:27 -0000." <199805311005.DAA20689@usr04.primenet.com> Date: Sun, 31 May 1998 14:11:37 +0200 Message-ID: <3354.896616697@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199805311005.DAA20689@usr04.primenet.com>, Terry Lambert writes: >> > 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. But the argument is nontheless badly flawed. This should be done by disallowing mknods by chrooted processes if such security is desired. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message