Bug 223984 - Zone transfers fail - wrong perm/ownership on /var/named/chroot/var/named
Zone transfers fail - wrong perm/ownership on /var/named/chroot/var/named
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: bind (Show other bugs)
4.4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Tkac
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-23 09:20 EST by Tethys
Modified: 2013-04-30 19:35 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-05 10:53:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tethys 2007-01-23 09:20:42 EST
Description of problem:
Jan 23 12:31:48 springfield named[11310]: received notify for zone 'example.com'
Jan 23 12:32:03 springfield named[11310]: zone example.com/IN: refresh: failure
trying master 89.106.176.217#53: timed out 
Jan 23 12:32:18 springfield named[11310]: zone example.com/IN: refresh: failure
trying master 89.106.176.217#53: timed out 
Jan 23 12:32:18 springfield named[11310]: dumping master file: tmp-XXXXPSW7dI:
open: permission denied
Jan 23 12:32:18 springfield named[11310]: transfer of 'example.com/IN' from
89.106.176.217#53: failed while receiving responses: permission denied
Jan 23 12:32:18 springfield named[11310]: transfer of 'example.com/IN' from
89.106.176.217#53: end of transfer

Version-Release number of selected component (if applicable):
bind-9.2.4-16.EL4

How reproducible:
Every time

Steps to Reproduce:
1. Set up bind as a slave.
2. Update the master
3. Watch the slave fail to update...


Additional info:

An strace shows it to be failing to write a temporary file to the current
directory (which is /var/named/chroot/var/named). That directory is owned
by root, and not writeable by the named user. A "chown named" fixed it
(I could have changed the permissions instead, but no user other than
named should ever really need to write to that directory anyway, so
chown seemed like the best bet). That fixed the problem, and the slave
was updated correctly.
Comment 1 Tethys 2007-01-23 13:21:13 EST
Sigh. This is not a bug, just a case of RH being different...

/etc/init.d/named was changing ownership of that directory back to root.

If I tell named to write the zone file to the slaves directory (to play
nicely with selinux) then it all seems to work.
Comment 4 Adam Tkac 2007-02-05 10:27:45 EST
(In reply to comment #1)

So if I understand correctly can I close this like notabug?
Comment 5 Tethys 2007-02-05 10:50:11 EST
Yes, you can.
Comment 6 Adam Tkac 2007-02-05 10:53:30 EST
closing

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