[Unbound-users] chrooting unbound, again

[Michael Tokarev]

Hello.

With root dnssec keys being now in place, I decided to
enable DNSSEC support in our unbound servers.  And
immediately hit another problem with chrooting.

We've chroot: /etc/unbound since it requires all the
configuration to be in the chroot directory for whatever
reason.  Our /etc is mounted read-only.

Now, we've a conflict: unbound wants BOTH all the
config files AND the files it updates in the same
directory.  This is what unix traditionally has
two separate dirs -- /etc and /var -- for.

Now, I can't keep it in /etc/unbound because unbound
wants to write to the file(s) in there and our /etc
is read-only.  I can't keep it in /var/lib/unbound
because the config files are and should be in /etc.

(There's another solution to this, -- copy config
files from /etc/unbound to /var/lib/unbound at
startup -- but this requires startup script modifications
(the startup script is supplied by the OS vendor and
it is subject to changes on upgrades), and I find
this method to be disgusting to start with.

Yet another way is offered by modern linux - ability
to "mount" (bind-mount) one file over another,
similar to symlink but that works across filesystem
boundaries and chroots - but this too is somewhat
disgusting.)

Why can't it just open everything at startup and
chroot later?

It already has a way to create .pid file outside
of the chroot jail, at least, which is a big plus.

Now when I think about it...  Unbound-control has
`reload' command, -- is it used to re-read all the
config files and is this a reason for unbound to
require all (config) files to be visible inside
chroot jail?  If it's the case, how about using
shared memory for the cache, so that unbound can
be restarted without dropping the cache?  No,
seriously, this may be not as bad idea - including
using a mmap'ed file (on a tmpfs) for the cache,
so it's possible to copy it to a persistent
storage during system shutdown etc...

Thanks!

/mjt