I wasn't CC'ed, thus the late reply. > But now I've a question: how the initial problem happened? > > Okay, it smells like it is, and it definitely it should not be > copied from /usr/share/dns/root.key..
What can I say? My /var partition became full (too many .deb files IIRC) and unbound.service wouldn't start because of an unusable trust anchor file (which was empty). How exactly that happened I have no idea. It may have been from unbound trying to replace root.key with its own changes and failing, but looking at the code (validator/autotrust.c:autr_write_file()) that should have left the old version in place upon failure. So maybe it was from package-helper trying to copy over the existing file for some other reason. Maybe due to the missing StateDirectory=/var/lib/unbound directive /var was not yet mounted when [ ! -e "$ROOT_TRUST_ANCHOR_FILE" ] ran fooling the script into thinking it should update that "missing" file, but became mounted before /usr/bin/install was invoked which then failed due to missing disk space leaving behind an empty file. The "-" in "ExecStartPre=-/usr/lib/unbound/package-helper root_trust_anchor_update" then resulted in this error being ignored which would have made it impossible for me to learn what exactly went wrong. Again, I have no way of reconstructing whether it happened like this, I'm just guessing here. As far as I see it a problem also was that (in the old version) after the reboot the package-helper script only tried to overwrite /var/lib/unbound/root.key when it was older than /usr/share/dns/root.key or missing, but not when it was empty or corrupted. Having package-helper automatically detect and try to auto-repair that would be a nice convenience to have as then simply restarting the unit would fix the problem. > The script (/usr/lib/unbound/package-helper) use install(1) to > update the file and to chown it (this also smells unsafe from the > security PoV). And install unlinks the destination file first, > creates destination file, writes contents to it, and closes it. It > looks like we should not use install(1) here, or maybe install it to > .tmp and mv it atomically, - and from _there_, the problem will just > go away. > ... > Am I right this is just the initial key and unbound updates this key > automatically by its own? I think so, but I'm not sure. My knowledge of both unbound and the details of DNSSEC is rather spotty. > > P.S.: I also noticed that unbound.service under [Service] defines no > > StateDirectory=/var/lib/unbound to ensure that it is mounted on start. > > The chroot setup procedure has its own load of issues. I see. Maybe adding just After=var.mount var-lib.mount var-lib-unbound.mount would still be worth considering. It would cause unbound.service to wait only if these mount units exist. And since /var/lib/unbound gets installed as part of the package this should not cause any problems even if unbound is run in chroot-mode. Regards.
