Red Hat Bugzilla – Bug 125518
Permissions on /var/named
Last modified: 2007-11-30 17:10:44 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
The permissions on the /var/named directory from the bind package with
Fedora Core 1 & 2 installed with root.named ownership and 750
permissions. This disallows the named daemon (running as the named
user) to write files to this location.
This breaks things like running a slave server: When a zone transfer
ocours, named will try to write the updated/new zone file in
/var/named and can't the result is "access denied" written to syslog,
which may make some folks think that the zone tranfer is disallowed,
instead of it being a local permissions issue (although the phrasing
of the error message is not a problem with the RPM!).
This breaks other things too, like where rndc stats and rndc dump_db
are not able to write the corresponding log files to the /var/named
directory where they belong.
I would suggest installing this directory mode 770 instead of the
current 750 to resolve this issue. If there is a compelling reason not
to do this, I'd love to be educated.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install the bind RPM package.
2. Observe the permissions on /var/named with 'ls -ld /var/named'
Actual Results: Permissions show as mode 750
Expected Results: Permissions show as mode 770
Slave files should be put into a subdirectory owned by named. The
idea is to protect the named config files from a hacker breaking into
named. THis way they can read but not modify named files. Slave
files are a special case and need to be put in a subdirectory.
How about the situation where zones allow dynamic updates, requiring
that the named daemon have write permissions to this directory?
Wouldn't this qualify for another special case? Or rndc dump_db?
Both cases should be handled by subdirs.
The bind RPM from Red Hat 9 used to install /var/named owned by
named.named, mode 755. This gives named (the daemon) write access to
named (the directory) from the onset. I thought the idea was that
folks concerned about a compromised named daemon would utilize
Basically, it used to work out-of-the-box, and it doesn't any more.
Maybe this change was made in the name of security, but it smelled an
awful lot like a bug to me. This seems a lot like installing the
apache RPM with a default DocumentRoot that isn't readable by httpd.
I'm having a tough time believing this is intentional when it looks
broken from my perspective.
Hello, Just looking for a little validation here. Basically:
bind package from Red Hat 9 installs /var/named as named.named 755.
bind package from Fedora Core 1/2 installs root.root 755.
Is this NOTABUG or am I ASCREWLOOSEBEHINDTHEKEYBOARD?
Thanks for your time, keep up the good work :)
/var/named should only be readable by the named process, If you need
slave files you need to create a subdirectory where named has
ownership. The idea is to protect the contents of the /var/named
directory from expoits of the named program.
The idea was to overcome known named security vulnerabilites.
Slave zones should be placed in /var/named/slaves.
Dumps & stats files should go into /var/named/data.
If you want to enable dynamic dns, either put the zone files
in a different directory owned by named or change the ownership
of the /var/named directory to named:named - by doing so, you
explictly accept the secuirity risk.
Does anyone run BIND as a slave server actually?
After BIND receives the response of AXFR request, BIND try to save it
to temporary file under /var/named (/var/named/chroot/var/named).
Logged messages are below:
Oct 26 21:02:01 x31 named: running
Oct 26 21:02:01 x31 named: dumping master file: tmp-XXXXrN9vKS:
open: permission denied
Oct 26 21:02:01 x31 named: transfer of 'example.co.jp/IN' from
210.xxx.yyy.xxx#53: failed while receiving responses: permission denied
I checked it under the bind-9.2.4-1.
Is this NOTABUG or am I ...?
Sorry, but please ignore #8 comment.
I configured named.conf incorrectly.
Just to knock this bug on the head:
The zone file directory ($ROOTDIR/var/named) now has ownership
root:named - this was intentionally to address known security
If SELinux is enabled, named write access to this directory and
its files can be granted by setting the SELinux boolean
'named_write_master_zones' to 1 :
# setsebool named_write_master_zones 1
Otherwise, without SELinux you must set the ownership of the
directory to named:named:
# chown named:named $ROOTDIR/var/named
I hope this clarifies things.
Only five months in the works... and all I was looking for was an
explanation. Something like, "The bind package from Fedora Core 1/2
has been changed to support SELinux and now installs root.root 755. If
you don't like this, use 'setsebool named_write_master_zones 1'"
Instead of "You're a jerk and don't know how to use bind- make a new
directory, set the permissions yourself and away you go".
Momma didn't raise no fool, she raised RHCE #809003186608620.