Description of problem: After the latest bind updates, the directory /var/named/chroot/var/named/master, where I keep the master zone files in all of the machines I manage, had mysteriously been chmoded to 640, preventing named from looking up files in it, so named wouldn't even start. Bad! :-) While at that, I've also noticed that on some recent update, not necessarily the latest, yum update would print errors about /usr/sbin/bind-chroot-admin not being present. I suppose some %post script was relying on it without a corresponding Requires, but I haven't been able to determine exactly which package was at fault, because I was running yum over ssh without a terminal, so yum wasn't sufficiently verbose :-( This was on an everything install. Version-Release number of selected component (if applicable): bind-9.3.2-14.FC5 How reproducible: Every time Steps to Reproduce: 1.create /var/named/chroot/var/named/master/ 1.install the latest bind updates Actual results: it removes the lookup (execute) bit from the newly-created directory Expected results: Ideally it shouldn't mess with what it doesn't know. I'm actually quite ok with it limiting permissions, but if it's to do that, it must recognize directories and preserve the lookup permissions in them, perhaps descending into them and fixing permissions of files in them as well. Additional info:
A possible work around for this problem is to copy all the own zone files from the master directory to the named directory (one level up) and edit the named.conf to reflect those changes.
Sorry about that - the next update (bind-9.3.2-16.FC5+) will not change permissions of any $ROOTDIR/var/named/ directory other than slaves/ or data/. NOTE: you are confusing the named SELinux policy by putting your master files in a subdirectory of $ROOTDIR/var/named/ - why not work with the policy by moving your zone files to $ROOTDIR/var/named/ ?
Thanks. The reason is that I keep the zone files in CVS, and IIRC at some point CVS didn't like the fact that the directory I checked files into already existed, or already contained files, or had extraneous permissions or some such. When slaves was introduced, I thought that was a good idea and started using masters/ myself :-) At that time, it worked fine with SELinux. Nowadays, I haven't been able to use SELinux in enforcing mode for other reasons (still haven't figured out how to customize policies for local needs yet, after the revamp that removed local.te :-), so I haven't got to adjusting named as needed. That said, AFAICT, the directories and files are labeled correctly, so it looks like it's going to work.
This bug is now fixed with bind-9.3.2-16.FC5, shortly to be released to FC-5 Updates/Testing.
bind-9.3.2-16.FC5 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Looks good to me, thanks! Sorry about the slow response.
The bind installation in FC5 (upgrade from FXC3) messed up all the file permissions in /var/named. Furthermore bind was installed although it was not installed according to RPM and destroyed my custom installation of bind.