Red Hat Bugzilla – Bug 187529
bind update breaks permissions of local subdirectories of var/named
Last modified: 2007-11-30 17:11:29 EST
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):
Steps to Reproduce:
1.install the latest bind updates
it removes the lookup (execute) bit from the newly-created directory
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.
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
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.