named: the working directory is not writable

mgp

mgp

Hi,
I've been seeing this complaint for some time and I'm still not sure what exactly the problem is
I see this in /var/log/messages when I start named:
Code: 
named[1284]: starting BIND 9.4.3-P1 -t /var/named -u bind
named[1284]: command channel listening on 127.0.0.1#953
named[1284]: the working directory is not writable
named[1284]: running
and when I do
Code: 
# chown -R bind /var/named
and start named again I get this:
Code: 
# /etc/rc.d/named start
. changed
        user expected 0 found 53 modified
etc changed
        user expected 0 found 53 modified
etc/namedb changed
        user expected 0 found 53 modified
etc/namedb/master changed
        user expected 0 found 53 modified
var changed
        user expected 0 found 53 modified
Starting named.
and the same in /var/log/messages:
Code: 
named[1541]: starting BIND 9.4.3-P1 -t /var/named -u bind
named[1541]: command channel listening on 127.0.0.1#953
named[1541]: the working directory is not writable
named[1541]: running
and the owner of /var/named is set back to root

what is this caused by and how do I fix it ? :)
thank you

regards
mgp
 
It is what's called "programmer inflected useless warnings".

The directory option is used for 2 things:
- The working directory for named
- The base directory for relative path references

For some reason named finds it worth mentioning that it can't write anything in this directory since a few releases. Conventional setups have not written in the named base dir for decades, but all of a sudden it's important to spit into logfiles.

If you really want this message to go away, you will need to change the directory option, like:
Code: 
options {
    // Paths
    directory           "/etc/namedb/letskeepthisdirwriteable";
}
As a result all your relative path references need to be rewritten, like:
Code: 
zone "." {
    type slave;
    file "[B][color="Red"]../[/color][/B]slave/root.slave";
    masters {
        192.5.5.241;    // F.ROOT-SERVERS.NET.
    };
    notify no;
};

I found it better to just ignore this warning.
 
I run named in jail (not freebsd jail) and keeping a writable directory won't make any difference. Infact I need writable directory so that query log written to /var/named/chroot/var/log directory and later it can be used by rrdtool (bindgraph.pl) to create nice graphs. Also, I keep security logs so I need directory writable.
 
vivek said:
I run named in jail (not freebsd jail) and keeping a writable directory won't make any difference. Infact I need writable directory so that query log written to /var/named/chroot/var/log directory and later it can be used by rrdtool (bindgraph.pl) to create nice graphs. Also, I keep security logs so I need directory writable.
Click to expand...

It's not about /var/named/chroot/var/log, it's about whatever directory you have set in named.conf as the 'directory' option. If unset, compiled in default is used, which is /etc/namedb. You don't want this directory writeable as any hole in Bind will allow the attacker to instantly rewrite named.conf and do nasty things.
 
This can be solved by changing

# $FreeBSD: src/etc/mtree/BIND.chroot.dist,v 1.6.20.1 2009/04/15 03:14:26 kensmith$
#
# Please see the file src/etc/mtree/README before making changes to this file.
#

/set type=dir uname=bind gname=wheel mode=0755 << this line used to contain uname=root instead
 
Sorry to reboot an old thread but what's wrong with this picture? Were you guys just born? I've been using FreeBSD for decades and in recent years over several versions of BIND I've never had this error. What was the deal on those machines? Were they configured writable by default, or has something in the configuration or reporting in BIND changed?

And isn't the sandbox set up so that you can be insulated against that kind of risk if you enable directory write?
 
InspectorGadget said:
And isn't the sandbox set up so that you can be insulated against that kind of risk if you enable directory write?
Click to expand...

The named.conf gets copied from /etc/named to /var/named/etc/namedb so bind can access it, so if you make /var/named writable then an attacker, despite not being able to escape from the sandbox, could still rewrite named.conf.
 
I have this same issue, but I can't ignore it.

/var/log/messages
Code: 
named[96348]: transfer of 'domain/IN' from a.b.c.d#53: failed while receiving responses: permission denied
named[96348]: dumping master file: /etc/namedb/tmp-Ubg6isB4J2: open: permission denied

This is because it tries to create a new temporary file but has no permission to do so.

How to solve this? :|
 
The way I solved it is in the post however this isn't the proper solution, ..

This can be solved by changing

# $FreeBSD: src/etc/mtree/BIND.chroot.dist,v 1.6.20.1 2009/04/15 03:14:26 kensmith$
#
# Please see the file src/etc/mtree/README before making changes to this file.
#

/set type=dir uname=bind gname=wheel mode=0755 << this line used to contain uname=root instead
Click to expand...

Few weeks ago I got a reply from FreeBSD team which solved the problem.

Code: 
Synopsis: named(8): the working directory is not writable

State-Changed-From-To: open->closed
State-Changed-By: dougb
State-Changed-When: Sat Mar 13 21:42:38 UTC 2010
State-Changed-Why: 

This problem has already been fixed in more recent versions of FreeBSD.
You should update, in rough order of precedence, to 8-stable, 8.0-RELEASE,
7-stable, or 7.3-RELEASE (when it comes out). Bonus points for being
part of the solution by testing a 7.3 release candidate. 

hope this helps,

Doug

http://www.freebsd.org/cgi/query-pr.cgi?pr=134616

I hope this helps ?

EDIT: I'm not sure if this is the same problem though.
 
Savagedlight said:
I have this same issue, but I can't ignore it.
Click to expand...
Different issue. Yours is a configuration error.

/var/log/messages
Code: 
named[96348]: transfer of 'domain/IN' from a.b.c.d#53: failed while receiving responses: permission denied
named[96348]: dumping master file: /etc/namedb/tmp-Ubg6isB4J2: open: permission denied

This is because it tries to create a new temporary file but has no permission to do so.
Click to expand...

You need to store that zone data in the /etc/named/slave/ directory.
 
I am also getting these error messages on the start up console and in the logs.

Currently using 8.0-Release, but also saw it 7.2-Release.
 
Unfortunately, you cannot just ignore it anymore. At least with BIND 9.14 (installed from packages). I tried it on a machine running FreeBSD 12.1 and encountered this problem:
Code: 
named[24831]: the working directory is not writable
named[24831]: loading configuration: permission denied
named[24831]: exiting (due to fatal error)
First, I decided bind doesn't have a permission to access one of its configuration files, but after few hours of reading and trying the solutions read (then reading and trying again and again), it all ended up with the working directory recursively owned by bind and bind started manually (rc script for bind silently resets directory permissions, that I was unaware of, and that made finding the reason for bind fail a bit more complicated). After that bind started successfully. Then I rewoke writing permissions for working directory for bind. Bind failed to start. So this is not just a warning anymore.

Since I don't want for a static dns server to be able to write anything on the machine, I reverted to BIND 9.11. This guy works fine even with unwritable working directory.
 
This error typically happens when upgrading from BIND 9.11 to BIND 9.14 or later. The issue is that BIND used owner root and group wheel for the /usr/local/etc/namedb directory. When BIND 9.14 was released they changed the requirement to owner bind group bind for /usr/local/etc/namedb. The fix is as follows:

chown bind:bind /usr/local/etc/namedb

There is no error message in the /var/log/messages file outside of "the working directory is not writable". Hope this helps.
 
You must log in or register to reply here.
Back
Top