Bug 115024 - bind doesn't preserve umask on xfer'd slave zone files
bind doesn't preserve umask on xfer'd slave zone files
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: bind (Show other bugs)
2.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-05 11:53 EST by Pete Fritchman
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-05 12:06:04 EST
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 Pete Fritchman 2004-02-05 11:53:17 EST
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.
Comment 1 Daniel Walsh 2004-02-05 12:06:04 EST
Have you tried updating to the latest one from RawHide?

Dan
Comment 2 Pete Fritchman 2004-02-05 12:59:43 EST
I'll try this on a test host and let you know if we see success.  On
our production hosts, we're required to only use official upstream
RPMs in the AS2.1 repo.

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