managed-keys.bind's directory problem

Doug Barton dougb at
Mon Dec 14 01:40:19 UTC 2009

On Fri, 11 Dec 2009, Mark Andrews wrote:
> In message <20091210.162242.460114267490885968.fujiwara at>, fujiwara at wid
> writes:
>> I'm using BIND 9.7.0b3 an DLV (dns-lookaside auto;).
>> The named tried to write "managed-keys.bind" file into the named's
>> working directory.
>> The current BIND 9 requires the working directory is writable by named
>> (From ARM). But I think the working directory should not be writable
>> by named and some OSs' default configuration set the working directory
>> not writable.
> Then those OS's are misconfiguring named.

Or, named is acting in an unsafe way. :) For example, see for my 
proposal to separate the idea of "working directory" from "configuration 
directory," and some of the reasons why.

To repeat my primary objection, if the named user can write to the 
configuration directory it can change the contents of named.conf. That's a 
security problem.

> This has been a requirement since the BIND 4 days.  It's just named has 
> not complained

Actually it does complain:
named[970]: the working directory is not writable

> and there has been loss of functionality as a result.

I would argue that this really hasn't been the case for FreeBSD, up till 
this point there has been a workaround for all of the functionality that 
users have asked for.

> On some OS's this is the only way to get a core file for debugging as 
> there is no way to specify anything other than the current working 
> directory.

Once again, I assert that this is a design flaw in named. Processes should 
not be dumping random stuff into the same directory where their 
configuration files go. It may have been acceptable back in the BIND 4 
days, but it's time to move on.

> Note there is no requirement for named's config files to be below the
> working directory.

This is something that I'll explore. I still prefer the solution to 
separate the idea of config and working directories. Imagine a scenario 
where the configuration stuff is on a read-only partition for example.

> The working directory does not have to be /var/named.

In FreeBSD (as in other OSs that I looked at for examples) that's the root 
of the chroot directory structure.

>> I'm very happy if I can change the managed-keys.bind path.
> We will look into that.

That would be good. I would argue that for any new feature configurability 
for its file location(s) should be a requirement.



 	Improve the effectiveness of your Internet presence with
 	a domain name makeover!

More information about the bind-users mailing list