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 <obsd_m...@chrissmith.org> wrote: > On Mon, Dec 30, 2013 at 6:10 PM, Remi Locherer <remi.loche...@relo.ch> 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