Description of problem: dumping master file: tmp-gqQyNt6CFq: open: permission denied Version-Release number of selected component (if applicable): bind-9.7.2-3.P2.fc14.x86_64 How reproducible: Every update and or install Steps to Reproduce: 1.start service 2. 3. Actual results: Expected results: Additional info: ls -l drwxr-x---. 5 root named 4096 Nov 17 14:58 /var/named Named is running as named and is not able to create data directory and dump files. Changed owner of directory to named to fix issue. Also noticed that /var/named/named.ca was not owned by named.
(In reply to comment #0) > ls -l drwxr-x---. 5 root named 4096 Nov 17 14:58 /var/named > > Named is running as named and is not able to create data directory and dump > files. Changed owner of directory to named to fix issue. Also noticed that > /var/named/named.ca was not owned by named. Non-writeable /var/named is intentional. May I ask you what's the tmp-gqQyNt6CFq file? Is it s secondary zone? Or is it a zone dumpfile (created via "rndc dumpdb", for example)? There are three writeable directories which should be used instead of /var/named for writeable files - /var/named/slaves, /var/named/dynamic and /var/named/data.
We saw this issue on both the primary and secondary. I just checked and now do not find any of these files that were in the /var/named/data directory. We saw the issue on start up and are not using rndc. So we should change owner ship back to root for the /var/named directory? What about the other files that were not owned by named?
Tried changing owner ship back to root for directory /var/named and the permissions issue showed up again. From /var/log/messages: Nov 22 17:28:49 hemlock named[21690]: dumping master file: tmp-8ruf5TI4fT: open: permission denied Since I do not find any files I'm assuming an attempt was to create them in the /var/named directory as named owns everything else under this directory and the the permissions are drwxr-x--- which would not allow a file to be created when root owns the directory.
Do you have SELinux enabled? Can you try to check if the error is still present when you disable it, please? (via `setenforce 0`, for example)
After further inspection I've been able to reproduce this issue. BIND implements mechanisms written in RFC 5011 which make possible to automatically update DNSSEC keys. Those dynamically updated keys are stored in the "fake" zone which is located, by default, in /var/named directory which is not writeable by named user. You need to set following option in your /etc/named.conf in the options section to solve this issue: options { ... managed-keys-directory "/var/named/dynamic"; ... }; With this option named will put all information related to DNSSEC keys updates into dynamic/ subdirectory which is writeable. Note this option is set in F14 default configuration. Closing as notabug.