named: the working directory is not writable [Archive]

View Full Version : named: the working directory is not writable

mgp

February 2nd, 2009, 20:37

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:
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
# chown -R bind /var/named
and start named again I get this:
# /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:
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

Mel_Flynn

February 12th, 2009, 07:09

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:

options {
// Paths
directory "/etc/namedb/letskeepthisdirwriteable";
}

As a result all your relative path references need to be rewritten, like:

zone "." {
type slave;
file "../slave/root.slave";
masters {
192.5.5.241; // F.ROOT-SERVERS.NET.
};
notify no;
};

I found it better to just ignore this warning.

vivek

February 13th, 2009, 09:53

Mel_Flynn

February 18th, 2009, 17:39

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.

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.

Ofloo

May 17th, 2009, 15:44

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

SirDice

May 17th, 2009, 17:46

Which will make the directory writable and susceptible to the attack Mel_Flynn mentioned. Hence it is not recommended.

InspectorGadget

November 8th, 2009, 00:30

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?

brucec@

December 11th, 2009, 21:54

And isn't the sandbox set up so that you can be insulated against that kind of risk if you enable directory write?

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.

Savagedlight

March 24th, 2010, 04:39

I have this same issue, but I can't ignore it.

/var/log/messages
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? :|

Ofloo

March 24th, 2010, 11:24

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

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

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.

SirDice

March 24th, 2010, 11:48

I have this same issue, but I can't ignore it.
Different issue. Yours is a configuration error.

/var/log/messages
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.

You need to store that zone data in the /etc/named/slave/ directory.

chrcol

March 25th, 2010, 04:06

I also am seeing it in the logs.

regarding the freebsd reply the machine I see it on is 8-STABLE

jaywheeler

June 14th, 2010, 04:11

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.

SirDice

June 14th, 2010, 13:10

Ignore it.