Red Hat Bugzilla – Bug 103703
up2dating breaks bind-chroot config
Last modified: 2007-11-30 17:10:31 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
Description of problem:
Up2dating a box from Severn to Severn updates causes named to stop functioning
properly. The problem is that the ROOTDIR line goes missing from
/etc/sysconfig/named, so zone transfers fail with obscure messages like this:
Sep 3 20:31:07 free named: dumping master file: tmp-XXXXQte7dF: open:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.Set up /var/named/chroot/etc/named.conf so as to be slave of some zones
3.up2date -u bind bind-chroot
Actual Results: /var/log/messages contains messages like the one above
Expected Results: if it used the chroot before, it should probably keep on
using after update
Still a problem with 9.2.2.P3. Additional annoyances are that (i) it creates
dev/null.rpmsave and dev/random.rpmsave inside the chroot, and (ii) it clobbers
the named.conf file in the chroot, not even caring about .rpmsaveing the original.
Fixed in bind 9.2.2.P3-4
chroot moves will only happen on installs not upgrades.
Err.. It didn't fix it for me. dev/null.rpmsave was still created, and
/etc/sysconfig/named still lost ROOTDIR=/var/named/chroot in the update.
Unfortunately, I didn't check whether named.conf was preserved.
Lets try it again 9.2.2.P3-5
Hmm... -5 creates dev/null.rpmnew, which is almost just as pointless, and it
still removes the ROOTDIR=/var/named/chroot from /etc/sysconfig/named :-(
named.conf was preserved in the chroot, though.
My previous note should have said 9.2.2.P3-6
I believe this is the final fix. :^(
Nope... -6 still creates dev/null.rpmnew, and upgrading from -5 still removes
the ROOTDIR=/var/named/chroot from /etc/sysconfig/named :-( Oddly, downgrading
to bind-chroot -5 retains ROOTDIR, but upgrading to -6 again removes it.
Oh... And I hadn't realized that the .rpmnew files that upgrading bind-chroot
creates are not devices files, but rather empty regular files. That's *very* odd.
Yet another problem: the permissions in /var/named/chroot/var/named were changed
from named:named to root:named. This is wrong. Just like /var/named, you need
named:named in order for named to be able to update zone files in the chrooted
-9 seems to have fixed all of the problems above, except for the permissions of
var/named, both in the chroot and outside it. I see you've added a `slaves'
subdir, but this is bad in that it requires changes to existing named.conf
files, i.e., updates to bind would break working configurations.
What's the point of requiring /var/named to be owned by root? This has never
been an issue before (quite the contrary; named has required /var/named to be
owned by named, not root, for quite a while), and I don't see any chroot-related
issue that could lead to privilege scalation.
I have also noticed that test3 no longer uses the named chroot by default, like
test1 did. Was this change interntional?
There was a bug that snuck into Test 3, It has been fixed in Rawhide.
Basically I was trying to get the initial install to work differently then
upgrades and the first try was broken.
As far as the problem with protection, I had a bugzilla security problem with
this. Basically if you have nameserver files that you are authoritative for in
this directory and they are owned by named or named has write permission to this
directory, you have a potential security problem. You see if a hacker breaks
into the named service and is able to get a shell account, he would have it as
named. If the directory and files in the directory are owned by root the hacker
can not change them to alter name resolution for the environment.
Confirmed, removing and reinstalling both bind and bind-chroot,
/etc/sysconfig/named comes back with chroot enabled by default. This, and the
need for moving slave zone files to the slaves subdir, should probably be
mentioned in the release notes.