• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

named: the working directory is not writable

mgp

Active Member

Thanks: 13
Messages: 108

#1
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
 

Mel_Flynn

Well-Known Member

Thanks: 77
Messages: 379

#2
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.
 

vivek

Aspiring Daemon

Thanks: 194
Messages: 809

#3
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.
 

Mel_Flynn

Well-Known Member

Thanks: 77
Messages: 379

#4
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.
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

Active Member

Thanks: 7
Messages: 237

#5
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

Administrator
Staff member
Administrator
Moderator

Thanks: 5,998
Messages: 26,766

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

InspectorGadget

New Member


Messages: 1

#7
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@

New Member
Developer

Thanks: 2
Messages: 18

#8
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?
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

Well-Known Member

Thanks: 96
Messages: 370

#9
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? :|
 

Ofloo

Active Member

Thanks: 7
Messages: 237

#10
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.

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.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Thanks: 5,998
Messages: 26,766

#11
Savagedlight said:
I have this same issue, but I can't ignore it.
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.
You need to store that zone data in the /etc/named/slave/ directory.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Thanks: 5,998
Messages: 26,766

#14
Ignore it.
 
Top