Bug 187529 - bind update breaks permissions of local subdirectories of var/named
bind update breaks permissions of local subdirectories of var/named
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-31 12:46 EST by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: bind-9.3.2-16.FC5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-17 13:28:59 EDT
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 Alexandre Oliva 2006-03-31 12:46:44 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):
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:
Comment 1 Tiger!P 2006-04-01 12:32:11 EST
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.
Comment 2 Jason Vas Dias 2006-04-01 12:48:03 EST
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/ ?
Comment 3 Alexandre Oliva 2006-04-01 13:28:53 EST
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.
Comment 4 Jason Vas Dias 2006-04-03 12:49:42 EDT
This bug is now fixed with bind-9.3.2-16.FC5, shortly to be released to 
FC-5 Updates/Testing.
Comment 5 Fedora Update System 2006-04-04 12:11:52 EDT
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.
Comment 6 Fedora Update System 2006-04-17 11:43:15 EDT
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.
Comment 7 Alexandre Oliva 2006-04-17 13:28:59 EDT
Looks good to me, thanks!  Sorry about the slow response.
Comment 8 Jørgen Thomsen 2006-05-01 06:00:26 EDT
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.

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