Bug 149572 - named init script makes /var/named unwritable - selinux
named init script makes /var/named unwritable - selinux
Status: CLOSED DUPLICATE of bug 145664
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2005-02-23 19:01 EST by Trevor Cordes
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:08:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Trevor Cordes 2005-02-23 19:01:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Description of problem:
I was getting strange errors where dynamic DNS records were not being updated when new Windows clients connected to my samba network.  I determined that the permissions on /var/named were incorrect.  They were root:named 750 when they should be named:named 750.  Since it was not writable, named could not associate WINS names with the DNS entries and I had subtle network issues because of it.

Lines 49-52 in /etc/init.d/named are to blame.  They must be fairly new as this never occurred before about a month ago.

It is obvious from the source script that named_write_master_zones should be set to 1 in /etc/selinux/*/booleans.

I use selinux in WARN-only mode.  Since the above lines are most likely an addition to BIND just for selinux's sake, then shouldn't the default be permissive, especially if selinux is in WARN mode?  Quietly changing the perms on /var/named because of some other piece of software is bad form, no?  The solution is not readily apparent and most likely there is no mention of named_write_master_zones in man named*!

Version-Release number of selected component (if applicable):
bind-9.2.4-8_FC3 selinux-policy-targeted-1.17.30-2.75

How reproducible:

Steps to Reproduce:
1. turn on selinux (warn mode will suffice)
2. service named restart

Actual Results:  /var/named permissions do not allow writes by named and some functions of named fail.

Expected Results:  It should not change the permissions/ownership by default.

Additional info:
Comment 1 Jason Vas Dias 2005-02-25 14:55:56 EST
This is now fixed in bind-9.2.5rc1-1 (FC3) / bind-9.3.1rc1-1 (FC4).

If SELinux is not disabled, the setting of 'named_write_master_zones'
will determine whether $ROOTDIR/var/named has ownership named:named
(named_write_master_zones=1) or root:named (named_write_master_zones=0).

If SELinux is disabled, if the variable 'ENABLE_ZONE_WRITE' is 
set to 'yes'/'1' in /etc/sysconfig/named, then the ownership 
of  $ROOTDIR/var/named is set to named:named; if  'ENABLE_ZONE_WRITE'
is set to 'no'/'0', the ownership of  $ROOTDIR/var/named is set to
root:named; if ENABLE_ZONE_WRITE is not set, the ownership of
$ROOTDIR/var/named is unchanged. 

This automatic setting of the $ROOTDIR/var/named was to minimise
the impact of the change of ownership of $ROOTDIR/var/named to
root:root to counter known security vulnerabilities as mandated 
by our security response team.

Now, with SELinux, DDNS and slave zone writes can be enabled through
use of the system-config-security GUI only, without extra steps 
having to be taken by the administrator to set the ownership of the
/var/named directory.

*** This bug has been marked as a duplicate of 145664 ***
Comment 2 Red Hat Bugzilla 2006-02-21 14:08:13 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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