named: the working directory is not writable

mgp

Active Member

Reaction score: 13
Messages: 106

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

Reaction score: 81
Messages: 379

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

Reaction score: 197
Messages: 805

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

Reaction score: 81
Messages: 379

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

Well-Known Member

Reaction score: 13
Messages: 322

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

Reaction score: 11,949
Messages: 38,390

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

InspectorGadget

New Member


Messages: 1

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

Reaction score: 2
Messages: 18

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

Reaction score: 100
Messages: 369

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

Well-Known Member

Reaction score: 13
Messages: 322

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

Reaction score: 11,949
Messages: 38,390

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.
 

chrcol

Well-Known Member

Reaction score: 51
Messages: 479

I also am seeing it in the logs.

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

jaywheeler

New Member


Messages: 1

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.
 

bmth

New Member

Reaction score: 3
Messages: 10

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.
 
Top