TSIG with BIND requires chmod+chgrp /etc/namedb

[Kevin Darcy]

Dan Langille wrote:

> On 1 Nov 2002 at 10:22, Cricket Liu wrote:
>
> >
> > Dan Langille wrote:
> > > It appears that using TSIG with BIND for secondary domains requires a
> > > chmod and chgrp of /etc/namedb.
> > >
> > > I've been adding TSIG to varioius domains.  But I've found that on my
> > > slave servers, I've had to set the directory permissions as this:
> > >
> > > $ ls -ld /etc/namedb/
> > > drwxrwxr-x  4 root  bind  512 Oct 15 09:26 /etc/namedb/
> > > $ ls -ld /etc/namedb/secondary/
> > > drwxr-x---  2 bind  bind  512 Oct 15 09:25 /etc/namedb/secondary/
> > >
> > > The original permissions on /etc/namedb are:
> > > drwxr-xr-x  2 root  wheel  512 Mar  9  2002 /etc/namedb
> > >
> > > named is running as:  /usr/sbin/named -u bind -g bind
> > >
> > > Some bits from /etc/namedb/named.conf:
> > >
> > > options {
> > >         directory "/etc/namedb";
> > >
> > > I don't really liked having to change the permission of /etc/namedb
> > > especially as that will be necessary for people runnning secondary
> > > DNS for me.
> > >
> > > Any comments/suggestions?
> > >
> > > [I'm using named 8.3.3-REL on FreeBSD 4.6-stable]
> >
> > I don't see why TSIG would require that the name server be able to
> > write to the working directory.  The name server would need to be
> > able to read the named.conf file or whatever file contained the key
> > definition, but that's it.
>
> It sounds like you do not believe me.... ;)
>
> Unless I do those chmod's, I get these errors:
>
> named[41288]: starting (/etc/namedb/named.conf).  named 8.3.3-REL Wed
> Jul 31 09:19:38 PDT 2002
> root at nezlok.example.org:/usr/obj/usr/src/usr.sbin/named
> named[41288]: limit files set to fdlimit (1024)
> named[41289]: Ready to answer queries.
> named[41289]: write_tsig_info: mkstemp(tsigs.i0FeEp) for TSIG info
> failed
> named[41289]: unable to write tsig info: 'example.com'

Yeah, it appears that BIND 8 writes TSIG keys into a temporary file. In
20/20 hindsight, perhaps it would have been smarter for it to chdir() into
the directory of the associated inbound zone transfer.

NOTE: I just tested BIND 9.2.2rc1 in this scenario and it doesn't appear to
have the same problem. So I guess the short answer is "upgrade".


- Kevin