Bug 115024

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6)
Gecko/20040126

Description of problem:
There is a known bug in versions of BIND earlier than 9.3 where xfer'd
slave zone files always end up with file permissions of 0600,
regardless of the inherited umask.

The bug lies in the BIND code when they use an internal mkstemp()
function and hardcode 0600 perms on temp files, and then rename() the
temp file to the final destination (i.e. /etc/namedb/slave/db.foo.com)
which perserves the 0600 permissions.

This bug has been fixed in BIND 9.3 (see a mailing list post here from
an upstream BIND maintainer:
http://marc.theaimsgroup.com/?l=bind9-users&m=104404872314221&w=2)

I'd be happy with an updated bind 9.3 RPM, or applying the specific
patch that lets my slave zone files get created with appropriate
permissions, specified by the inherited umask.

Version-Release number of selected component (if applicable):
bind-9.2.1-1.7x.2

How reproducible:
Always

Steps to Reproduce:
1. Create a named.conf that will transfer a slave zone locally.
2. Make sure the slave zone file doesn't already exist.
3. Set your umask to 022.
4. Start named. (named -u named or /etc/init.d/named start)
5. Inspect the slave zone file created, and note it's permissions are
0600 (should be 0644 with the inherited umask).

Actual Results:  All the slave zone files ended up mode 0600.

# find /etc/namedb/slave -type f \! -perm 0600 -ls
#


Expected Results:  The zone files should be mode 0644.  In bind 8, and
bind 9.3:

-rw-r--r--  1 named  named   61184 Feb  5 10:22 slave/db.foo.com



Additional info:

We have a non-root (and not user named) process that needs to inspect
the secondary zone files to make sure they're being slaved correctly
(we compare serial numbers).  We currently can't do this on our
nameservers running RedHat AS2.1 and the supplied bind RPM due to the
stated problem.