From owner-freebsd-hackers Sun Jul 25 16:21:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from snafu.adept.org (adsl-63-193-112-19.dsl.snfc21.pacbell.net [63.193.112.19]) by hub.freebsd.org (Postfix) with ESMTP id 3ACE515266; Sun, 25 Jul 1999 16:21:42 -0700 (PDT) (envelope-from mike@snafu.adept.org) Received: from localhost (mike@localhost) by snafu.adept.org (8.9.3/8.9.3) with ESMTP id QAA24805; Sun, 25 Jul 1999 16:20:50 -0700 (PDT) Date: Sun, 25 Jul 1999 16:20:50 -0700 (PDT) From: Mike Hoskins To: Sue Blake Cc: freebsd-hackers@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: sandbox?? In-Reply-To: <19990726040233.E7349@welearn.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Jul 1999, Sue Blake wrote: > If nobody understands how this sandbox thing works, we should change > the named.conf that we supply. If somebody does, then they or someone Understanding a sandbox only requires the ability to read on the part of the user (something anyone in charge of named administration has hopefully learned, else they don't need to be administrating anything). As for the current named.conf format... I agree that it should be changed. Rc.conf currently references the fact that 'it may be possible to run named in a sandbox'. Named.conf says 'FreeBSD runs bind in a sandbox'. Saying FreeBSD does something one place while saying it may be possible to do it in another is... silly. The actual use is up to the administrator, so it seems logical to have named.conf examples for sandbox and non-sandbox configs. Mike Hoskins To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message