: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
:<m...@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 majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
