Bug 654475 - dumping master file: tmp-gqQyNt6CFq: open: permission denied
dumping master file: tmp-gqQyNt6CFq: open: permission denied
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
14
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-17 18:14 EST by David Highley
Modified: 2013-04-30 19:47 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-24 05:22:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Highley 2010-11-17 18:14:46 EST
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.
Comment 1 Adam Tkac 2010-11-22 10:19:24 EST
(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.
Comment 2 David Highley 2010-11-22 10:40:57 EST
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?
Comment 3 David Highley 2010-11-22 22:02:00 EST
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.
Comment 4 Adam Tkac 2010-11-23 11:30:38 EST
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)
Comment 5 Adam Tkac 2010-11-24 05:22:35 EST
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.

Note You need to log in before you can comment on or make changes to this bug.