Bug#989959: closed by Debian FTP Masters (reply to Michael Tokarev ) (Bug#989959: fixed in unbound 1.15.0-2)
19.04.2022 23:38, Dennis Filder wrote: I wasn't CC'ed, thus the late reply. I didn't know either, Dennis. I just replied to the bug :) 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 Yeah, I see it quite well now how exactly things went wrong, and you confirm my thoughts. And the root cause was using install/cp to create the file, -- neither of which do it atomically. So any error during the copy and we'll have some bad file out there. Even for a small file like this - today we have filesystems with inline data, when small files are written directly into the directory, and only for larger files a real extent is allocated, - this root.key is enough to flip from inline to extent (which we might not have). 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 It definitely is. Because install/cp which was used. ... 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 Because no one thought about possible partial file in there. It should never be partial. And this update ensures just that. Well, there still *is* a possibility here, but I don't know if any real modern filesystem allows this: a file should be comitted to disk before the final rename completes. ... 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. It is the initial value and unbound will keep it updated. P.S.: I also noticed that unbound.service under [Service] defines no StateDirectory=/var/lib/unbound to ensure that it is mounted on start. Hmm this is a good idea to add this. 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 I think StateDirectory helps here. Thank you! /mjt
Bug#989959: closed by Debian FTP Masters (reply to Michael Tokarev ) (Bug#989959: fixed in unbound 1.15.0-2)
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.
