Running unbound in a chroot: Which files need to be accessible?

[Timo Sigurdsson]

Hi Alexander,

thanks for your reply. Please see my comments below.

A. Schulze schrieb am 05.11.2018 18:16:
> Am 05.11.18 um 16:19 schrieb Timo Sigurdsson via Unbound-users:
>> Hi,
> 
> Hello Timo,
> 
>> I'm currently running unbound 1.8.0 on Linux (Debian) and wonder how to
>> properly set up the chroot environment ? especially which files need to be
>> accessible from within the chroot.
> I have "dev/random" and a copy of "etc/unbound/unbound.conf"
> 
>> 1) I'm using the tls-cert-bundle option in order to forward requests to
>> upstream servers that support DNS over TLS. The certificate bundle is outside
>> of unbound's configuration directory and chroot directory. In a quick test,
>> I'm able to run unbound in a chroot, without making the certificate bundle
>> available from within the chroot. So, I'm assuming the certificate bundle is
>> read before unbound enters the chroot and not accessed anymore afterwards. But
>> is this always true? Will unbound at some point need access to the
>> tls-cert-bundle from within the chroot?
> try something like "unbound-control reload" or "killall -HUP unbound".
> See if the PID is still the same and check if something break.
I ran some more tests as suggested and basically nothing breaks and the
PID stays the same. I have not included the cert-bundle in my chroot
and it continues to run fine even after a reload. More deails on
/dev/log and /run/systemd/notify below.

If someone could confirm that the cert-bundle is really not relaoded
even after a longer period of time, that would be nice. But I guess I
will figure it out at some point either way when I deploy this setup ;)

> To make remote control work, I set
<snip>
Debian has the control interface preconfigured by default, so I didn't
need to change anything here.

>> 2) On Debian with systemd, unbound is a service of the type "notify". A bug
>> report suggests that the socket /run/systemd/notify should be made accessible
>> from within the chroot[1]. Is this needed? During my little testing, it didn't
>> seem to make a difference whether the socket was bind mounted to the chroot or
>> not.
> unbound works fine without systemd, too :-)
Sure. But it still seems like a reasonable question for any systemd
user. During my further testing, I figured out the following:
While unbound will run just fine, without /run/systemd/notify being
accessible inside the chroot, it's better to expose the socket to the
chroot. Otherwise systemd will get "confused" about the state of
unbound, such as indicating that unbound is still starting or reloading
whereas it's up and running fine (or failed). I guess catching failures
is most relevant here. With the socket available inside the chroot,
systemd will show status changes instantly. So, unbound will make use
of it if it's there.


>> 3) The man page mentions that /dev/random should be accessible. Since I don't
>> run into errors when I set up the chroot without a bind mount for /dev/random,
>> I'm wondering whether access to /dev/random is only needed in certain
>> configurations? The same goes for /dev/log. But is this really needed
>> regardless of whether a log file or syslog is used for logging?
> I don't use bind mounts but simply run "mknod --mode 0666 $(CHROOT)/dev/random
> c 1 8"
> 
> I've no syslog at all but logging to STDOUT
I use syslog. But it seems /dev/log is not required inside the chroot.
It continues to log just fine to syslog even after a reload. I even
tested with stdout and stderr redirected to /dev/null to make sure it
logs via syslog. I found two old changelog entries indicating that
/dev/log is opened before the chroot is entered without the need to
reload it afterwards [1][2]. If someone could confirm that is still
true today, I'd suggest dropping the mention of /dev/log in the man
page.

[1] https://cbs.centos.org/koji/buildinfo?buildID=9705
[2] https://www.nlnetlabs.nl/svn/unbound/trunk/doc/Changelog
(search for "dev/log" inside these changelogs)

>> 4) Are there any other files/locations that should be made accessible inside
>> the chroot in order to ensure reliable operation, aside from the configuration
>> files and the auto-trust-anchor-file? If I look at the apparmor profile for
>> unbound, it seems a lot more files might be accessed, but of course that might
>> only be the case before chroot is entered.
> 
> If you configure auto-trust-anchor-file, these file are also required inside
> chroot.
I already had that included, thanks.

<snip>

Thanks and regards,

Timo