Bug 773595 - bind-chroot-admin changes /etc/named.conf owhership but doesn't change it's perms
bind-chroot-admin changes /etc/named.conf owhership but doesn't change it's p...
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: bind (Show other bugs)
x86_64 Linux
urgent Severity high
: rc
: ---
Assigned To: Tomáš Hozza
: ZStream
Depends On:
Blocks: 798457 836232 857056 865572
  Show dependency treegraph
Reported: 2012-01-12 06:16 EST by Greg Matthews
Modified: 2013-09-23 07:23 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 865572 (view as bug list)
Last Closed: 2013-09-23 07:23:05 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 Greg Matthews 2012-01-12 06:16:43 EST
Description of problem:
recent updates to bind and bind-chroot change the ownership of /var/named/chroot/etc/named.conf which results in bind not restarting.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.have custom chrooted bind configuration
2.upgrade bind\*
3.check that named is not running
Actual results:
named is not running and cannot be restarted. /var/named/chroot/etc/named.conf has ownership root:named instead of named:named. syslog shows:

Jan 12 10:49:30 serv007 named[9914]: loading configuration from '/etc/named.conf'
Jan 12 10:49:30 serv007 named[9914]: none:0: open: /etc/named.conf: permission denied
Jan 12 10:49:30 serv007 named[9914]: loading configuration: permission denied
Jan 12 10:49:30 serv007 named[9914]: exiting (due to fatal error)

Expected results:
named should restart correctly.

Additional info:
despite the syslog messages, /etc/name.conf is NOT required when chrooted. The following fixes the problem:

sudo shown named:named /var/named/chroot/etc/named.conf
Comment 1 Adam Tkac 2012-01-12 07:16:41 EST
Both /var/named/chroot/etc/named.conf and /etc/named.conf should have root:named ownership and both should have 640 permissions. Can you please check if your named.conf has correct perms? Did you modify default perms somehow?
Comment 2 Greg Matthews 2012-01-12 07:53:14 EST
my named.conf has permissions 0600. But it was working perfectly before the package update (and I could use /etc/init.d/named restart). The update altered permissions so that it no longer started - as it also involved a restart of the named process, the daemon died during the update with no warning.

I don't understand why the update changed the ownership of the file. It should not have touched what is a custom config file.
Comment 3 Greg Matthews 2012-01-12 07:54:30 EST
correction to the above, the update changed the /ownership/ of the file not the permissions.
Comment 4 Adam Tkac 2012-01-12 08:29:39 EST
Thanks for your feedback, now I understand why this happened.

When you have bind-chroot installed, the /usr/sbin/bind-chroot-admin script is executed every time when bind is updated. This script automatically changes ownership of the /etc/named.conf to root.named but it doesn't change it's perms, which is a bug.
Comment 5 Greg Matthews 2012-01-12 08:52:19 EST
aahh... I was not aware of this script. 

I agree that if it changes ownership it should also make sure perms are correct so that the daemon can start.

The other minor bug that is thrown up by this, is the syslog message referring to /etc/named.conf instead of $ROOTDIR/etc/named.conf.

thanks for the speedy attention - hope the fix makes it into the next release.
Comment 6 RHEL Product and Program Management 2012-04-02 06:31:26 EDT
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.
Comment 8 RHEL Product and Program Management 2012-06-11 21:13:35 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 9 Greg Matthews 2012-08-22 11:00:28 EDT
still not fixed I see. This was identified in january to be a bug in the bind-chroot-admin script. New releases of this package have been come and gone and it still silently fails to restart bind.

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