Red Hat Bugzilla – Bug 201161
permissions on /var/named/chroot/var/named broken during upgrade
Last modified: 2007-11-30 17:07:10 EST
Description of problem: permissions on /var/named/chroot/var/named changed to root during upgrade, named needs to write there in order for it to start I am running bind as a secondary with an additional private zone Version-Release number of selected component (if applicable): last few releases its happened everytime How reproducible: everytime Steps to Reproduce: 1. up2date bind 2. 3. Actual results: named will not restart Expected results: named restart Additional info: chown named /var/named/chroot/var/named fixes the problem /var/named/chroot/var/named is where my db files go perhaps I have them in the wrong place?
Have you checked the U8 update?
yes I had that applied last night and it broke bind I am running 9.2.4 14_EL3
hmm, root is the right owner for /var/named/chroot/var/named...
with drwxr-x--- root named /var/named/chroot/var/named strace -f -e trace=file /usr/sbin/named -u named -t /var/named/chroot shows open("named.pid", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EACCES (Permission denied) named trying to write named.pid to that directory and not having permission to perhaps /var/named/chroot/var/named should be group writable?
My installation writes /var/named/chroot/var/run/named/named.pid properly. You probably have a pid-file directive in your {/var/named/chroot/}/etc/named.conf. Remove it or change to (the default) /var/run/named/named.pid. Whatever you do, don't try to troubleshoot by running sysreport with /var/named/chroot/proc mounted (it tries to cp -rp /var/named, including all of /proc...).
removing the pid-file option sorts out restarting, thank you my zone data files are also in /var/named/chroot/var/named. I just set the ownership on them manually or should I move them too? -- I don't recall /var/named/chroot/proc being there before and, I would think, having it exposes information about processs outside the chroot and it creates the possiblity for escaping the chroot?
This is not a bug. You should change your slave zone files so that they point to different directory which named user has permission to write to. f.ex. "slaves/yourslavezone"