Description of problem: Bind permissions (chroot) do not allow transfer and update of slave zones. /var/named/chroot/var/named is owned by root and named group permissions are not writable. This error is probably related to fixes associated with Bugzilla 167682. Version-Release number of selected component (if applicable): bind-chroot-9.3.1-14 How reproducible: Startup of named service produces the following error during attempted transfer of slave zone: transfer of '172.in-addr.arpa/IN' from 172.22.22.11#53 failed while receiving responses: permission denied -also- dumping master file: tmp-xXdnkDIupZ: open: permission denied Steps to Reproduce: 1. Create slave zone in named.conf to known good primary master 2. (re)start named daemon (/etc/init.d/named (re)start) 3. Actual results: slave zone is NOT transferred Expected results: proper zone transfer Additional info: Error corrected by changing ownership of /var/named/chroot/var/named to named. Unfortunately, this reintroduces part of the security vulnerability noted in Bugzilla 167682 where all zone records become vulnerable. Master zone records with owner root within this directory is not a good solution either where dynamic updates will fail (and probably already are with the new permission structure). Also, error message is somewhat misleading where one can easily allow one to think that the transfer failed due to the master server configuration.
We provide the $ROOTDIR/var/named/slaves directory for the purpose of zone file transfers, which has the correct ownership and permissions (where $ROOTDIR is set in /etc/sysconfig/named). To use, change the 'zone "my.zone." IN { ... type slave; file 'my.zone.db'; ...};' to 'zone "my.zone." IN { ... type slave; file 'slaves/my.zone.db'; ...};' . This is documented in the Rawhide/FC5 named(8) and named_selinux(8) man-pages, which I will backport to FC-4 in the next bind release. Note that use of the bind-chroot environment is made redundant and the "security vulnerability" of bug 167682 you refer to is fixed by use of SELinux in Enforcing mode, which will not permit named to write any zone file unless the 'named_write_master_zones' boolean is true, regardless of the ownership / permissions of the $ROOTDIR/var/named directory. Note also that if SELinux is not in Enforcing mode or the named_write_master_zones boolean is set, and the ROOTDIR/var/named directory is writable by the named user, then named is open to the "vulnerability". This is named's default behaviour and it is up to administrators whether to accept this vulnerability or not . There is no way to "fix" this without coding named to be unable to write zone files in the $ROOTDIR/var/named directory, which would be totally unacceptable to the majority of bind administrators. There is no formal vulnerability (CVE/CAN #) regarding named being able to write its zone files.