Red Hat Bugzilla – Bug 773595
bind-chroot-admin changes /etc/named.conf owhership but doesn't change it's perms
Last modified: 2013-09-23 07:23:05 EDT
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): bind-libs-9.3.6-16.P1.el5_7.1.x86_64 bind-utils-9.3.6-16.P1.el5_7.1.x86_64 bind-chroot-9.3.6-16.P1.el5_7.1.x86_64 bind-9.3.6-16.P1.el5_7.1.x86_64 How reproducible: always. 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
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?
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.
correction to the above, the update changed the /ownership/ of the file not the permissions.
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.
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.
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.
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.
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.