Bug #44853 for bind9-public: [PATCH] NZF files cannot be written to different directory

Thank you for the patch, we'll review it. If it makes sense for managed-keys then it makes just as much sense for this. I'm curious why you're using a non-writable working directory, though? That will cause more problems than just this.

I've reviewed your patch, and made a few changes: - reverted the changes to dns_view_addnewzones(), put the allow code back into view.c. - moved your file_sanitize_legacy() function into view.c as nz_legacy() - made new-zones-directory a view option instead of options-only - added a dns_view_setnewzonedir() function. That's now used by nz_legacy() to find the right place to put the files - added documentation of new-zones-directory - noticed that the existing documentation of NZD and NZF files was rather poor, so expanded them - fixed the test to check for NZD instead of NZF when linked with LMDB (I want to thank you for writing a test, that was particularly helpful.) Since I changed your code a fair bit I'm going to ask one of my colleagues to review it too, but I expect this will be merged to our master branch (for 9.12.0) soon. Thank you again for the contribution.

Hi Evan, today I was checking my 9.11 instance with some stuff of dyndb. I noticed write errors of NTA files. I did not notice it before, because I do not use Bind 9.11 much yet. I am sure I would like to be able to change view->nta_file write directory as well. It is less important than nzf files for me right now. I do not like an idea of three options however, all of them with the same value. I think it would make sense to have one common option for all mkeys, nzf/nzd and nta files. With possible override for a specific type if required. It might be useful to have configuration type of "path to existing directory" maybe. It would not be required to copy path test and report and error in case specified directory did not exist. I am looking forward to merge back your changes. I will try to make similar backport to Bind 9.9 which we ship in RHEL. You are right about core dumps. We have coredumps handled by abrt tool in Fedora and RHEL. Without manual configuration, you will not get core dump in working directory in those distributions. Maybe also from derived ones. They are dumped into some system directory, where they are unreadable by ordinary user. That is important feature of packaged services, because it allows easier sending of core dumps (and more information) from our customers. Unfortunately most bugs from BIND are core dumps from memory leak detection, where I am not able to tell the reason for them. But it is good feature anyway. Dne 25.3.2017 v 07:28 Evan Hunt via RT napsal(a): > >> I think there are only dynamic zones with their journal. But they use >> temporary files in the same directory as themselves, aren't they? >> What other problems can it make? I can think only automatic DNSSEC >> resigning. Such zones are updated using dynamic updates anyway, aren't >> they? Selinux will log any access violation. The only problem reported >> by users was .nzf files. If you know any potential problems, I would >> really like to hear them. > > The most significant problem that's hard to correct with careful configuration > of named is that most platforms write core dumps to the working directory by > default, and changing that is usually a system-wide setting rather than something > that can be corrected specifically for named. It makes for difficult > debugging. > > But I do think you're correct that the files named has direct control over can > be configured to write elsewhere (with the exception of NZF and NZDB files, > which your patch addresses). >

On Mon, Apr 03, 2017 at 11:07:54AM +0000, Petr Menšík via RT wrote: > Do you have any use case when would it help to configure it per view? Not particularly, but as it's set as a view member internally, it seemed unnecessary for it to to be defined globally in the config file.