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[30792]: dumping master file: tmp-XXXXQte7dF: open: permission denied Version-Release number of selected component (if applicable): bind-9.2.2-22 How reproducible: Always Steps to Reproduce: 1.install Severn 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 Additional info:
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 Dan
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. :^( Dan
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 /var/named.
-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. Dan
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.