Bug 143438 - wrong permissions for /var/named/chroot/var/named/
wrong permissions for /var/named/chroot/var/named/
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-20 15:38 EST by Gene Czarcinski
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: bind-9.2.4-8_FC3, bind-9.3.0-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-14 13:09:13 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 Gene Czarcinski 2004-12-20 15:38:18 EST
Description of problem:
I have named configured and dhcpd configured to do dynamic dns
updates.  However, bind-chroot has set the file permissions so that
that the ".jnl" files cannot be created.  They are currently set to:

drwxr-x---  4 root  named 4096 Nov 13 16:54 named

and I believe they should be set to:

drwxrwx---  4 root  named 4096 Nov 13 16:54 named
Comment 1 Jason Vas Dias 2004-12-20 16:17:44 EST
Actually, the permissions of $ROOTDIR/var/named were set intentionally
this way at the request of the Red Hat Security response team, to 
counter known security vulnerabilities in BIND . 

If you are running with SELinux enabled, you need to set the SELinux
targeted policy boolean 'named_write_master_zones' to 1 to allow 
the named process to create its DDNS journal files or to replace 
its master zone files, and you need to do:  
  ( # chown named:named $ROOTDIR/var/named
    and 
    # chown named:named $ROOTDIR/var/named/{ DDNS updateable zone files }
  ) or 
    # chown -R named $ROOTDIR/var/named
to enable the correct file permissions for DDNS.

The next version (bind-9.2.4-4) will have this behaviour
implemented in the startup script (/etc/init.d/named):
   if ( ( SELinux is enabled and
          the 'named_write_master_zones' boolean is 1
        ) or
        ( SELinux is disabled and
          the $ALLOW_DNS variable is 1
        )  
      )and
       $ROOTDIR/var/named does not have ownership named:named:
         chown named:named $ROOTDIR/var/named/
         chown named:named {all zone files where allow-update != None}
    else
    if ( ( SELinux is enabled and
          the 'named_write_master_zones' boolean is 0
         ) or
         ( SELinux is disabled and
          the $ALLOW_DNS variable is 1
         )  
       )and
       $ROOTDIR/var/named does not have ownership root:named:
         chown root:named $ROOTDIR/var/named
         chown root:named {all zone files where allow-update != None}    
 
So in bind-9.2.4-4 you'll be able to set 
"ALLOW_DDNS=1" in /etc/sysconfig/named (if SELinux is disabled) or
"named_write_master_zones"=1 in /etc/selinux/targeted/booleans
(if SELinux is enabled)
and the permission issues will be taken care of.
Comment 2 Gene Czarcinski 2004-12-20 16:34:38 EST
I had initially disabled selinux for named and that is when I hit the
file permissions problem.  I have since found out about the selinux
named_write_master_zones boolean so that will enable turning selinux
back on.

Do you have an estimate as to when bind-9.2.4-4 will be available (I
notice that bind-9.3.0 is in development)?

BTW, I really believe that SELinux should be a bit more granular about
the zone files and only allow creating/updating the .jnl files --
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143440
Comment 3 Jason Vas Dias 2004-12-20 17:35:59 EST
 I'll try to issue an update of bind in FC3 to 9.2.4-4 and 
 in Rawhide to 9.3.0-2 by 2005-01-05. 
Comment 4 Jason Vas Dias 2005-01-14 13:09:13 EST
This is now fixed in :
   FC-3 updates: bind-9.2.4-8_FC3
   FC-4 rawhide: bind-9.3.0-2
These releases should be available on the normal channels from
tomorrow (2005-1-15) onwards.
If the named_write_master_zones SELinux boolean is enabled (1),
then the startup script will ensure that the $ROOTDIR/var/named
directory has ownership named:named. Else, it will ensure 
ownership root:named .

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