misc/145904: /etc/rc.d/named doesnt correctly handle chrooted directories

J R Matthews jrm at darktide.net
Wed Apr 21 05:30:02 UTC 2010

>Number:         145904
>Category:       misc
>Synopsis:       /etc/rc.d/named doesnt correctly handle chrooted directories
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Apr 21 05:30:01 UTC 2010
>Originator:     J R Matthews
>Release:        8.0-RELEASE-p2
FreeBSD abyss 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #4: Sat Mar 13 11:19:13 UTC 2010     root at titanium:/usr/obj/usr/src/sys/GENERIC  amd64
During the 'precmd' phase of /etc/rc.d/named, the 'named-checkconf' call doesn't take into account the $named_chrootdir variable and due to that, it doesn't called named-checkconf with a chroot set. This can cause issues if you are running a chroot'd named, and your configurations will not verify without the chroot.

If this were to behave correctly, the variable $named_chrootdir should be checked to see whether it's set and 'named-checkconf' called appropriately:

Something like:

        if [ -n "$named_chrootdir" ];; then
                ${command%/named}/named-checkconf -t $named_chrootdir $named_conf || err 3 'named-checkconf for $named_conf failed'
                ${command%/named}/named-checkconf $named_conf || err 3 'named-checkconf for $named_conf failed'

As my named.conf is setup in a specific way, due to these bad checks, I've had to modify my /etc/rc.d/named in the above way so that the config checks pass as they wouldn't otherwise.
Set your named.conf to reference something that's absolute to the named chroot, and watch the init script fail.
A suggested fix is provided above, wherein the $named_chrootdir variable is checked before calling named-checkconf in an appropriate way.


More information about the freebsd-bugs mailing list