>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
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Apr 21 05:30:01 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: J R Matthews
>Release: 8.0-RELEASE-p2
>Organization:
>Environment:
FreeBSD abyss 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #4: Sat Mar 13 11:19:13 UTC
2010 r...@titanium:/usr/obj/usr/src/sys/GENERIC amd64
>Description:
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'
else
${command%/named}/named-checkconf $named_conf || err 3
'named-checkconf for $named_conf failed'
fi
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.
>How-To-Repeat:
Set your named.conf to reference something that's absolute to the named chroot,
and watch the init script fail.
>Fix:
A suggested fix is provided above, wherein the $named_chrootdir variable is
checked before calling named-checkconf in an appropriate way.
>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
