This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 184035 - named zone transfer fails due to directory ownership
named zone transfer fails due to directory ownership
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-05 01:37 EST by Chris Tyler
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-05 14:37:26 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 Chris Tyler 2006-03-05 01:37:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7

Description of problem:
Zone transfers from master to slave servers fails because /var/named on the slave is owned by root:named instead of named:named.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Configure a zone master 'A' and slave 'B' for the domain 'foo.com'.
2. Start named on 'A' then 'B'.


Actual Results:  The zone transfer fails. The error message in /var/log/messages is: "dumping master file: tmp-ZK7Cgfm69I: open: permission denied"


Expected Results:  The zone transfer should have succeeded.

Additional info:

To fix the problem:
1. Execute 'chown named:named /var/named' on system 'B' (slave).
2. Restart named and observe that the zone transfer succeeds.
Comment 1 Jason Vas Dias 2006-03-05 14:37:26 EST
By default, our security policy does not allow named to write any files in the
$ROOTDIR/var/named zone database directory.

We provide a $ROOTDIR/var/named/slaves/ directory, that can contain zones that
named is allowed to modify, that can be created with named.conf statements such
as: 
'   zone "my.slave.net." { type slave; file "slaves/my.slave.zone"; ...}; 
' 
So, if you put named modifiable zone files in slaves/, you should have no 
zone transfer problems with the default named installation.
NOTE: each time the bind package gets updated, the directory permissions will 
be restored to defaults.

Also, the SELinux policy prevents named writing zone files in 
$ROOTDIR/var/named.

This issue is documented in the named(8) man-page, in the NOTES section, and
in the ISC BIND FAQ: http://isc.org/sw/bind/FAQ.php .

The bind security policy is as mandated by our security response team, and 
cannot be changed to allow writes of zone files in the $ROOTDIR/var/named
directory - sorry. 

So I'm closing this as 'NOTABUG'.  

But, for the next version of BIND, I will investigate making named emit a 
warning log message on startup if slave or DDNS updateable zone files are
stored in $ROOTDIR/var/named .
Comment 2 Chris Tyler 2006-03-05 15:13:34 EST
Thanks... My handwritten configs always used slaves/, but configuration
generated by system-config-bind does not use that subdirectory. So I suppose the
bug should be filed against system-config-bind... will do.

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