Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 103703 - up2dating breaks bind-chroot config
up2dating breaks bind-chroot config
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2003-09-03 19:49 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-19 00:17:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2003-09-03 19:49:18 EDT
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):

How reproducible:

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:
Comment 1 Alexandre Oliva 2003-10-02 16:25:33 EDT
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.
Comment 2 Daniel Walsh 2003-10-07 16:54:00 EDT
Fixed in bind 9.2.2.P3-4
chroot moves will only happen on installs not upgrades.
Comment 3 Alexandre Oliva 2003-10-07 17:13:24 EDT
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.
Comment 4 Daniel Walsh 2003-10-08 10:14:31 EDT
Lets try it again 9.2.2.P3-5

Comment 5 Alexandre Oliva 2003-10-08 16:19:19 EDT
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.
Comment 6 Daniel Walsh 2003-10-08 16:46:46 EDT
My previous note should have said 9.2.2.P3-6

I believe this is the final fix.  :^(

Comment 7 Alexandre Oliva 2003-10-09 02:05:36 EDT
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.
Comment 8 Alexandre Oliva 2003-10-09 02:06:57 EDT
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.
Comment 9 Alexandre Oliva 2003-10-09 16:04:54 EDT
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
Comment 11 Alexandre Oliva 2003-10-18 16:26:57 EDT
-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.
Comment 12 Alexandre Oliva 2003-10-18 16:27:55 EDT
I have also noticed that test3 no longer uses the named chroot by default, like
test1 did.  Was this change interntional?
Comment 13 Daniel Walsh 2003-10-19 00:17:29 EDT
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.

Comment 14 Alexandre Oliva 2003-10-19 13:51:15 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.