Chrooting unbound, again

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

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.

This is why SElinux is better then chroot(), and you should really
consider using that (if on linux) and not using chroot() at all.
See previous threads on this list before on chroot vs SElinux.

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.)

yeah, this was done in the past, and it is terrible to maintain as
well. The fedora/rhel packages now fully depend on SElinux, not chroot()

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

It needs to write to the key files for RFC5011 support. So in a way
you cannot have /etc/ readonly with that file in there. You might need
to move that into /var/

And yes, the whole signaling and adding /var/unbound/var/unbound symlinks
or equivalent is just a disaster (I remember those awful bind days with
about as much love as my sendmail.cf manual editing days)

Paul