re: CVS commit: src/external/bsd/bind/dist/bin/named
In article 22061.1240544...@splode.eterna.com.au, matthew green m...@eterna.com.au 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.
re: CVS commit: src/external/bsd/bind/dist/bin/named
On Apr 25, 1:31am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/external/bsd/bind/dist/bin/named |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. I take it that this dir means /var/chroot/named/etc/namedb, then perhaps yes. I agree although not 100%, since my current tree looks like: $ ls -al /var/chroot/named/etc/namedb drwxr-xr-x 6 root wheel 512 Jul 19 2008 ./ drwxr-xr-x 4 root wheel 512 Jul 19 2008 ../ -rw-r--r-- 1 root wheel 259 Dec 3 2004 127 -r--r--r-- 1 root wheel 1525 May 30 2008 Makefile drwxr-xr-x 2 root wheel 512 Feb 15 2006 RCS/ drwxr-xr-x 2 named named 512 Nov 4 2004 cache/ drwxr-xr-x 3 named named 512 Apr 23 2007 pri/ -r--r--r-- 1 root wheel 2517 Nov 1 2007 root.cache drwxr-xr-x 2 named named 3584 Apr 24 11:40 sec/ [my primary zones are in pri and my secondary zones in sec] And I don't really see the need to make the whole namedb directory owned by named. Even the pri directory does not need to be writable by named. | the bug here is that your named is running chrooted an unprived | in /var/chroot/named with cwd, not the etc/namedb subdir. Well, it needs to chroot there, but then it could chdir() to etc/namedb. I will look if this is feasible when I get some cycles. For now commenting out the test is the same behavior that we had in the previous versions of named. christos
Re: CVS commit: src/external/bsd/bind/dist/bin/named
chris...@zoulas.com (Christos Zoulas) writes: And I don't really see the need to make the whole namedb directory owned by named. Even the pri directory does not need to be writable by named. The only time named really needs to write to the config dir is for dynamic update. The only other time it writes is to dump a debugging file -- the latter is supposed to be done in /var/tmp though. Perry -- Perry E. Metzgerpe...@piermont.com
