Description of problem: The current unbound package does not support running in a chroot. We could add a new sub-package with unbound-chroot.service which would start unbound in the chroot (e.g. /var/lib/unbound). The subpackage should create and own the chroot filesystem. The service should: 1. prepare the chroot on start (bind-mount all necessary files into the chroot) 2. start the unbound in chroot 3. unmount all files from the chroot on service stop. Additional info: https://open.nlnetlabs.nl/pipermail/dnssec-trigger/2014-June/000327.html
I strongly prefer NOT to do this. Using chroot historically comes with many many problems with include file paths, lock files, pid files and reload/restart problems. This will be worse with unbound-control thrown into the mix. We don't want to deal with copying /etc/unbound/*.d directories into a chroot. There is nothing that we gain with chroot() that selinux and containers/cgroups does not already offer us. It was a very conscious decision made when I started packaging unbound to not support chroot(). Please let me know what specific feature chroot would give us that we currently do not have?
Does Unbound have a fairly restrictive SELinux policy? If yes, I don't really see that much value in chrooting, especially this isn't as easy as it used to be because of library dependencies and the required state management. (It would be bad if Unbound keeps running vulnerable binaries because the chroot environment is not updated.)
This is more a placeholder bug for request PJP raised on the dnssec-trigger-list. I agree that if running unbound in the chroot should complicate things even more without any benefit, it is not worth it. unbound runs in named_t as BIND. However I'm no expert to say if it is restrictive enough (although seems reasonable to me).
Since there seems to be no benefit of running unbound in a chroot, but rather more issues I'm closing this as WONTFIX.