Description of problem: postinstall scriptlet sets wrong permission (655) to directories in /var/named/chroot Version-Release number of selected component (if applicable): bind-9.2.4-2 bind-9.3.2-4_EL4 How reproducible: Always Steps to Reproduce: 1. install bind without bind-chroot 2. setup DNS server directories (here e.g. we have 3 directories for 3 virtual NS servers) 3. install bind-chroot Actual results: # ll /var/named/chroot/var/named/ total 104 drw-r-xr-x 2 named named 4096 Aug 28 12:06 CVS drwxrwx--- 2 named named 4096 Aug 25 2004 data -rw-r--r-- 1 named named 198 Aug 26 2004 localdomain.zone -rw-r--r-- 1 named named 195 Aug 26 2004 localhost.zone -rw-r--r-- 1 named named 415 Aug 26 2004 named.broadcast -rw-r--r-- 1 named named 2518 Aug 26 2004 named.ca -rw-r--r-- 1 named named 432 Aug 26 2004 named.ip6.local -rw-r--r-- 1 named named 433 Aug 26 2004 named.local -rw-r--r-- 1 named named 416 Aug 26 2004 named.zero drw-r-xr-x 4 named named 4096 Aug 28 12:06 ns.domain1.example <- !!! drw-r-xr-x 4 named named 4096 Aug 28 12:06 ns.domain2.example <- !!! drw-r-xr-x 3 named named 4096 Aug 28 12:06 ns.domain3.example <- !!! drwxrwx--- 2 named named 4096 Aug 28 12:06 slaves Expected results: permissions 0750 for such directories, not 0655 Additional info: Looks like a typo in postinstall scriptlet triggers this bug: safe_replace /etc/named.conf "/var/named/chroot/etc/named.conf" root named 644 "$default_ndc" /usr/bin/find /var/named -xdev -type f | /bin/egrep -v '/var/named/chroot' | while read f; do d=`/usr/bin/dirname $f`; if test '!' -d "/var/named/chroot$d"; then mkdir -p "/var/named/chroot$d"; chown named:named "/var/named/chroot$d"; chmod 655 "/var/named/chroot$d"; <-!!!!!! should 750 fi; safe_replace $f "/var/named/chroot$f" named named 644 '' || :; done # ll /var/named/ total 84 drwxrwx--- 5 root named 4096 Aug 28 12:06 chroot drwxr-xr-x 2 root root 4096 Aug 28 12:06 CVS drwxrwx--- 2 named named 4096 Feb 21 2005 data lrwxrwxrwx 1 root root 44 Aug 28 12:06 localdomain.zone -> /var/named/chroot/var/named/localdomain.zone lrwxrwxrwx 1 root root 42 Aug 28 12:06 localhost.zone -> /var/named/chroot/var/named/localhost.zone lrwxrwxrwx 1 root root 43 Aug 28 12:06 named.broadcast -> /var/named/chroot/var/named/named.broadcast lrwxrwxrwx 1 root root 36 Aug 28 12:06 named.ca -> /var/named/chroot/var/named/named.ca lrwxrwxrwx 1 root root 43 Aug 28 12:06 named.ip6.local -> /var/named/chroot/var/named/named.ip6.local lrwxrwxrwx 1 root root 39 Aug 28 12:06 named.local -> /var/named/chroot/var/named/named.local lrwxrwxrwx 1 root root 38 Aug 28 12:06 named.zero -> /var/named/chroot/var/named/named.zero drwxrws--- 4 root named 4096 Aug 28 12:06 ns.domain1.example drwxrws--- 4 root named 4096 Aug 28 12:06 ns.domain2.example drwxrws--- 3 root named 4096 Aug 28 12:06 ns.domain3.example drwxrwx--- 2 named named 4096 Aug 28 12:06 slaves BTW: It can be also discussed why the directories are not removed after copy and soft-linked back, but this is another more low-prio issue. "bind-chroot-admin" which supersets postinstall scriptlet in FC5 and FC6 does not contain the permission bug.
Have you installed package bind-chroot?
Yes, in step 3 (note that named runs in non-chroot config before, but switched to bind-chroot now during maintenance). I reproduced this by rpm -e bind-chroot, rm -rf /var/named/chroot/; rpm -i bind-chroot. Note also that my soft link "btw" comment was not 100% ok, I found that soft links are created in the directory (e.g. /var/named/ns.domain1.example/zone -> /var/named/chroot/ns.domain1.example/zone ). Anyway, also not a good idea, because if I add a new zone (which I have to do now in directory /var/named/chroot/ns.domain1.example/, who maintain the softlink automagically?) - so it would be better that safe_replace replaces moved directories with a softlink, not the directory contents.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
The named group needs write permission on /var/named/chroot/var/named otherwise attempts to make that bind a slave for a domain will fail with: dumping master file: tmp-XXXXQm9pNM: open: permission denied
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0711.html