re: CVS commit: src/external/bsd/bind/dist/bin/named

[matthew green <mrg%eterna.com.au@localhost>]

   In article <22061.1240544853%splode.eterna.com.au@localhost>,
   matthew green  <mrg%eterna.com.au@localhost> wrote:
   >   
   >   Modified Files:
   >    src/external/bsd/bind/dist/bin/named: server.c
   >   
   >   Log Message:
   >   Don't log if "." is not writable. In the chrooted environment this is
   >   "/var/chroot/named", and there is no reason whatsoever for this to be
   >   writable!
   >
   >
   >this seems bogus to me.
   >
   >this check seems to be about making sure it can write secondary
   >files.  it's a good check.
   >
   >
   >for my named chroot setup a9hich i've been using since before
   >both netbsd or bind-proper had them, but using the same basic
   >technique of named user/group & chroot), i kept named chdiring
   >into, eg, /var/chroots/named/etc/namedb and that dir was
   >writable, but the toplevel chroot dir was not.
   >
   >please restore this check and fix the usage.
   >
   >
   
   I don't think you are right here:
   
   $ ls -l /var/chroot/named/
   total 8
   drwxr-xr-x  2 root  wheel  512 Jun  3  2005 dev/
   drwxr-xr-x  4 root  wheel  512 Oct  2  2005 etc/
   drwxr-xr-x  3 root  wheel  512 May 22  2005 usr/
   drwxr-xr-x  4 root  wheel  512 May 22  2005 var/
   
   This is like root, and I have security issues changing the permissions there.
   Named has no business having write access there.

i'm not saying change this.
   
   Perhaps you are confusing this directory with /var/chroot/named/etc/namedb?

i'm saying that named should be configured to have this dir as
the cwd and then the permissions check you removed will pass.

the bug here is that your named is running chrooted an unprived
in /var/chroot/named with cwd, not the etc/namedb subdir.
   

.mrg.