Thinking about this further, where would root.key be put if unbound
were not running in a chroot? Probably /var/unbound, and since we
already have a /var/unbound/var then the root.key file (and any others
that the _unbound user may need access to could (and maybe should) go
into /var/unbound/var/unbound (?). If so, this diff works for the
current rc file:
=====================
--- unbound.orig Mon Dec 30 11:03:51 2013
+++ unbound Tue Dec 31 09:26:18 2013
@@ -8,6 +8,17 @@
. /etc/rc.d/rc.subr
pexp="unbound${daemon_flags:+ ${daemon_flags}}"
+
+autotrust() {
+ if ! [[ -d /var/unbound/var/unbound ]]; then
+ mkdir "/var/unbound/var/unbound"
+ chown _unbound:_unbound "/var/unbound/var/unbound"
+ chmod 775 "/var/unbound/var/unbound"
+ fi
+ sudo -u _unbound /usr/local/sbin/unbound-anchor -a
"/var/unbound/var/unbound/root.key"
+ wait
+}
+
rc_reload=NO
rc_pre() {
@@ -16,6 +27,7 @@
-f /var/unbound/etc/unbound_control.pem ]]; then
unbound-control-setup >/dev/null 2>&1
fi
+ autotrust
}
rc_start() {
=====================
Also the unbound.conf file must be edited so that the autotrust line reads:
auto-trust-anchor-file: "/var/unbound/var/unbound/root.key"
Another way would be to keep the current rc file as is and use a
separate rc pkg script to handle grabbing the root key. The user would
place it in rc.conf.local before calling unbound:
pkg_scripts="unbound-anchor unbound"
Chris
On Mon, Dec 30, 2013 at 6:45 PM, Chris Smith <[email protected]> wrote:
> On Mon, Dec 30, 2013 at 6:10 PM, Remi Locherer <[email protected]> wrote:
>> Having the root.key in a separate directory works.
>
> Yes, it works. But "/var/unbound/etc" was the choice during configure
> which means a little more work:
> The autotrust path line in unbound.conf needs to be edited with the
> new root.key path.
> The new autotrust path must be specified when running unbound-anchor
> (or the compiled in default will be used).
> The new autotrust directory must be created with proper permissions.
>
> It's not a big deal, and it would maybe add a line or two to the
> proposed function addition to the rc file, but it would be better to
> just adjust the configure options when building the package if it's so
> dangerous to provide the daemon write access to its own configuration
> directory. I figured if the package creator compiled in those defaults
> they should be used instead of my original workaround (adding the
> directory, etc.).
>
> Chris
