Description of problem: The script uses "grep" logic to determine if it's chroot'ed proc is mounted. However, the check is performed with a variably named root directory. If the root dir string ends in a "/" then the search term to grep is incorrect and proc isn't properly mounted/unmounted. Steps to Reproduce: 1. Start the named service 2. Stop the named service (proc is not unmounted). 3. Start the named service (get error message about proc already being mounted) ()
Created attachment 117412 [details] fix for problem but may not be complete solution in all situations.
The workaround is of course NOT to append a trailing '/' onto the $ROOTDIR setting in /etc/sysconfig/named, or to mount the procfs on /var/named/chroot/proc in /etc/fstab . The more general fix would be this line in /etc/init.d/named, @line 29: ' [ -n "$ROOTDIR" ] && ROOTDIR=`echo $ROOTDIR | sed 's#//*#/#g;s#/$##'` ' This would deal with any sequence of '/'s in $ROOTDIR: $ ROOTDIR=///////var///named/////////////////chroot////////////// $ [ -n "$ROOTDIR" ] && ROOTDIR=`echo $ROOTDIR | sed 's#//*#/#g;s#/$##'` $ echo $ROOTDIR /var/named/chroot This change will go into the next BIND version. Note that use of the bind-chroot environment is made redundant by use of SELinux in Enforcing mode; you gain no security by using bind-chroot with SELinux Enforcing, and can safely do 'rpm -e bind-chroot' .
Agreed, though for a name server running on cheap "non-beefy" hardware, the performance impact of SELinux is a factor. Since I am one to run a name server on they-don't-make-it-like-they-use-to-hardware, chroot is a nice alternative :)
The performance impact for SELinux using targeted policy should be pretty negligible. You probably need to try that
Closing bugs in MODIFIED state from prior Fedora releases. If this bug persists in a current Fedora release (such as Fedora Core 5 or later), please reopen and set the version appropriately.