While entering the chroot should provide the same amount of isolation,
the preStart script will run with full root privileges and so would
benefit from some isolation as well (in particular due to
unbound-anchor, which can perform network I/O).
1. The preStart script ensures consistent ownership, even if the unbound
user's uid has changed
2. The unbound daemon does not generate data that needs to be private to
it, so it would not matter that a different service would end up
owning its data (as long as unbound remains enabled, it should reclaim
ownership soon enough anyway).
Thus, there's no clear benefit to allocate a dedicated uid for the
unbound service. This releases uid/gid 48.
Also, because the preStart script creates the data directory, there's no
need to specify a homedir or ask for its creation.
/dev/random is an exhaustible resource. Presumably, unbound will not be
used to generate long-term encryption keys and so allowing it to use
/dev/random only increases the risk of entropy exhaustion for no
benefit.
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.