Date: Sun, 25 Jul 1999 21:59:33 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mike Hoskins <mike@snafu.adept.org> Cc: Sue Blake <sue@welearn.com.au>, freebsd-hackers@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: sandbox?? Message-ID: <199907260459.VAA42863@apollo.backplane.com> References: <Pine.BSF.4.10.9907251613520.24644-100000@snafu.adept.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
:<mike@adept.org>
The sandbox code for bind is not a novice exercise, which is why it is
commented out by default. This is mainly because bind insists on doing
things which make sandboxing difficult - you can't HUP it, for example,
or bring interfaces down and up. The comment in the sample named.conf
is wrong, it isn't on by default. Bind has a number of design faults
that make it difficult to run outside of root. It would probably
work in a jail(), though, if someone wants to work on that.
The sandbox for the comsat and ntalk daemons does work and is on by
default.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907260459.VAA42863>