Bug 201161 - permissions on /var/named/chroot/var/named broken during upgrade
permissions on /var/named/chroot/var/named broken during upgrade
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: bind (Show other bugs)
3.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Martin Stransky
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-03 06:07 EDT by Neil Prockter
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-18 07:30:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Neil Prockter 2006-08-03 06:07:32 EDT
Description of problem:
permissions on /var/named/chroot/var/named changed to root during upgrade, named
needs to write there in order for it to start
I am running bind as a secondary with an additional private zone

Version-Release number of selected component (if applicable):
last few releases its happened everytime

How reproducible:
everytime

Steps to Reproduce:
1. up2date bind
2.
3.
  
Actual results:
named will not restart

Expected results:
named restart

Additional info:
chown named /var/named/chroot/var/named fixes the problem
/var/named/chroot/var/named is where my db files go perhaps I have them in the
wrong place?
Comment 1 Martin Stransky 2006-08-03 07:17:16 EDT
Have you checked the U8 update?
Comment 2 Neil Prockter 2006-08-03 07:39:36 EDT
yes I had that applied last night and it broke bind
I am running 9.2.4 14_EL3
Comment 3 Martin Stransky 2006-08-04 09:48:21 EDT
hmm, root is the right owner for /var/named/chroot/var/named...
Comment 4 Neil Prockter 2006-08-04 10:17:03 EDT
with
drwxr-x--- root named  /var/named/chroot/var/named

strace -f -e trace=file /usr/sbin/named -u named -t /var/named/chroot

shows
open("named.pid", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EACCES (Permission denied)

named trying to write named.pid to that directory and not having permission to

perhaps /var/named/chroot/var/named should be group writable?
Comment 5 Rich Graves 2006-08-04 21:08:28 EDT
My installation writes /var/named/chroot/var/run/named/named.pid properly. You
probably have a pid-file directive in your {/var/named/chroot/}/etc/named.conf.
Remove it or change to (the default) /var/run/named/named.pid.

Whatever you do, don't try to troubleshoot by running sysreport with
/var/named/chroot/proc mounted (it tries to cp -rp /var/named, including all of
/proc...).
Comment 6 Neil Prockter 2006-08-05 05:33:44 EDT
removing the pid-file option sorts out restarting, thank you

my zone data files are also in /var/named/chroot/var/named. I just set the
ownership on them manually or should I move them too?

--
I don't recall /var/named/chroot/proc being there before and, I would think,
having it exposes information about processs outside the chroot and it creates
the possiblity for escaping the chroot?
Comment 7 Tuomo Soini 2006-08-16 03:09:35 EDT
This is not a bug. You should change your slave zone files so that they point to
different directory which named user has permission to write to. f.ex.
"slaves/yourslavezone"

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