I updated my secondary DNS server from 5.3 to 5.4 today. After the update, named would not start. A bit of investigation found that all of the files in /var/named/chroot/var/named/data had been turned into links to themselves!
Fortunately, since this is a secondary DNS, all I had to do was delete the files, replace the root hints file and let everything else copy back over from the master. If this had been the master, I would have had to restore from backups.
Has anyone else seen this problem?
Bowie Bailey wrote on Tue, 19 Jan 2010 15:51:40 -0500:
Has anyone else seen this problem?
No. I usually see some change in the permissions (/var/named/chroot/var/named/ loses group write and named logs some complaints but still works) when updating named. I think I've seen this happen several times and with the last update as well. I've not taken this serious as it didn't stop named from working. I assume the write permissions are only necessary for client DNS updates which I do not use. I remember there was a more serious problem a year or so ago, when an update stopped named from working because it overwrote some files. So, the upgrading experience has been less smooth with named than with other packages, but I haven't seen what you experienced.
Kai
Kai Schaetzl wrote on Tue, 19 Jan 2010 23:31:33 +0100:
No. I usually see some change in the permissions (/var/named/chroot/var/named/ loses group write and named logs some complaints but still works) when updating named.
And sure enought that happened with latest bind update today again.
/var/named/chroot/var l drwxrwx--- 2 named named 4096 Jan 20 17:33 log drwxr-x--- 4 root named 4096 Jan 20 17:33 named drwxr-x--- 4 root named 4096 Mar 14 2003 run drwxrwx--- 2 named named 4096 Mar 14 2003 tmp
I usually set g+w for the named directory. I wonder now if the owner of that directory should actually be named? Thanks.
Kai
Kai Schaetzl wrote on Thu, 21 Jan 2010 13:00:48 +0100:
I wonder now if the owner of that directory should actually be named?
Hm, after looking on other machines that have named installed but not in use it's excactly the same there. So, if named wants write permission there, but the rpm always removes that permission - isn't the rpm wrong then? Should I report this as a bug?
Kai
Kai Schaetzl wrote:
Kai Schaetzl wrote on Thu, 21 Jan 2010 13:00:48 +0100:
I wonder now if the owner of that directory should actually be named?
Hm, after looking on other machines that have named installed but not in use it's excactly the same there. So, if named wants write permission there, but the rpm always removes that permission - isn't the rpm wrong then? Should I report this as a bug?
On my system, named does not have write permission to the named directory, but it does have permission to named/data.
# ll /var/named/chroot/var/ total 24 drwxr-x--- 4 root named 4096 Aug 25 2004 named drwxrwx--- 3 root named 4096 Mar 13 2003 run drwxrwx--- 2 named named 4096 Mar 13 2003 tmp
# ll /var/named/chroot/var/named/ total 16 drwxrwx--- 5 named named 4096 Sep 25 14:25 data drwxrwx--- 2 named named 4096 Jul 27 2004 slaves
Everything is working fine for me with these settings, so I don't think this is a problem.
Bowie Bailey wrote on Thu, 21 Jan 2010 09:34:02 -0500:
# ll /var/named/chroot/var/ total 24 drwxr-x--- 4 root named 4096 Aug 25 2004 named drwxrwx--- 3 root named 4096 Mar 13 2003 run
that has no group write permission here.
drwxrwx--- 2 named named 4096 Mar 13 2003 tmp # ll /var/named/chroot/var/named/ total 16 drwxrwx--- 5 named named 4096 Sep 25 14:25 data drwxrwx--- 2 named named 4096 Jul 27 2004 slaves
Same here.
Everything is working fine for me with these settings, so I don't think this is a problem.
It seems to be working, but I get this complaint (I see it as a complaint) each time named gets restarted - until I give it write permission for that directory.
- The directory that does contain the zone files appears to be owned by
named with write permissions by default.
This would be data then. Yes, same here. And the files in it are owner/group named and rw for both.
- All of my master zone files are owned by root with 644 permissions,
so regardless of the directory permissions, named can't mess with them.
I have them even 640. owner root, group named.
Kai
It seems to be working, but I get this complaint (I see it as a complaint) each time named gets restarted - until I give it write permission for that directory.
This is RedHat's policy for bind. The working directory does not need to be writable, and RH's bind maintainer Adam Tkac has explained this on numerous occasions.
Lhecking@users.sourceforge.net wrote on Thu, 21 Jan 2010 16:48:10 +0000:
This is RedHat's policy for bind. The working directory does not need to be writable, and RH's bind maintainer Adam Tkac has explained this on numerous occasions.
Thanks for the hint. I cannot see that he explained that "on numerous occasions", but I can see some bug reports about this, for instance http://www.mail- archive.com/fedora-package-announce@redhat.com/msg26692.html As long as they keep doing this and *not* change the reporting at the same time they will get questions about it.
Kai
On Thu, Jan 21, 2010 at 8:20 AM, Kai Schaetzl maillists@conactive.com wrote:
Kai Schaetzl wrote on Thu, 21 Jan 2010 13:00:48 +0100:
I wonder now if the owner of that directory should actually be named?
Hm, after looking on other machines that have named installed but not in use it's excactly the same there. So, if named wants write permission there, but the rpm always removes that permission - isn't the rpm wrong then? Should I report this as a bug?
Kai
I don't think you'd want a compromised named to be able to make changes to your authoritative DNS records, which is what could happen if you have permissions set that way.
Brian Mathis wrote:
On Thu, Jan 21, 2010 at 8:20 AM, Kai Schaetzl maillists@conactive.com wrote:
Kai Schaetzl wrote on Thu, 21 Jan 2010 13:00:48 +0100:
I wonder now if the owner of that directory should actually be named?
Hm, after looking on other machines that have named installed but not in use it's excactly the same there. So, if named wants write permission there, but the rpm always removes that permission - isn't the rpm wrong then? Should I report this as a bug?
Kai
I don't think you'd want a compromised named to be able to make changes to your authoritative DNS records, which is what could happen if you have permissions set that way.
1) The directory he was referring to does not contain the zone files. 2) The directory that does contain the zone files appears to be owned by named with write permissions by default. 3) All of my master zone files are owned by root with 644 permissions, so regardless of the directory permissions, named can't mess with them. 4) The secondary server's zone files have to be writable by named so they can update from the master.
I don't see a problem here.
Brian Mathis wrote on Thu, 21 Jan 2010 09:38:12 -0500:
I don't think you'd want a compromised named to be able to make changes to your authoritative DNS records, which is what could happen if you have permissions set that way.
But why does named then report it right after the update?
Jan 21 12:46:40 chacha named[16607]: the working directory is not writable
Kai
Kai Schaetzl wrote:
Brian Mathis wrote on Thu, 21 Jan 2010 09:38:12 -0500:
I don't think you'd want a compromised named to be able to make changes to your authoritative DNS records, which is what could happen if you have permissions set that way.
But why does named then report it right after the update?
Jan 21 12:46:40 chacha named[16607]: the working directory is not writable
I experienced same message when upgrading bind on freebsd recently. After googling, I settled down, seems that its exactly as it must be. Only that message shold be more precise and add at the end something like "... good!".
On Tue, Jan 19, 2010 at 3:51 PM, Bowie Bailey Bowie_Bailey@buc.com wrote:
I updated my secondary DNS server from 5.3 to 5.4 today. After the update, named would not start. A bit of investigation found that all of the files in /var/named/chroot/var/named/data had been turned into links to themselves!
Fortunately, since this is a secondary DNS, all I had to do was delete the files, replace the root hints file and let everything else copy back over from the master. If this had been the master, I would have had to restore from backups.
Has anyone else seen this problem?
-- Bowie
Do you have the caching-nameserver package installed? I've heard this can cause problems with files getting overwritten.
On 1/19/2010 5:26 PM, Brian Mathis wrote:
On Tue, Jan 19, 2010 at 3:51 PM, Bowie BaileyBowie_Bailey@buc.com wrote:
I updated my secondary DNS server from 5.3 to 5.4 today. After the update, named would not start. A bit of investigation found that all of the files in /var/named/chroot/var/named/data had been turned into links to themselves!
Fortunately, since this is a secondary DNS, all I had to do was delete the files, replace the root hints file and let everything else copy back over from the master. If this had been the master, I would have had to restore from backups.
Has anyone else seen this problem?
-- Bowie
Do you have the caching-nameserver package installed? I've heard this can cause problems with files getting overwritten.
If you install the caching-nameserver package it assumes you don't have any other configuration (that's that point of it being a caching-nameserver).
Les Mikesell wrote:
On 1/19/2010 5:26 PM, Brian Mathis wrote:
On Tue, Jan 19, 2010 at 3:51 PM, Bowie BaileyBowie_Bailey@buc.com wrote:
I updated my secondary DNS server from 5.3 to 5.4 today. After the update, named would not start. A bit of investigation found that all of the files in /var/named/chroot/var/named/data had been turned into links to themselves!
Fortunately, since this is a secondary DNS, all I had to do was delete the files, replace the root hints file and let everything else copy back over from the master. If this had been the master, I would have had to restore from backups.
Has anyone else seen this problem?
-- Bowie
Do you have the caching-nameserver package installed? I've heard this can cause problems with files getting overwritten.
If you install the caching-nameserver package it assumes you don't have any other configuration (that's that point of it being a caching-nameserver).
Nope, no caching-nameserver here. All I have is:
bind-libs-9.3.6-4.P1.el5_4.1 bind-utils-9.3.6-4.P1.el5_4.1 bind-chroot-9.3.6-4.P1.el5_4.1 bind-9.3.6-4.P1.el5_4.1
-
Bowie Bailey -
Brian Mathis -
Kai Schaetzl -
Les Mikesell -
lhecking＠users.sourceforge.net -
Veiko Kukk