Slave db file permissions

[Cherney John-CJC030]

Thank you all for your responses. I meant to include the version of BIND
I am running (8.3.3 on Solaris 9). I apologize for leaving out that
detail.

I want to protect the slave db files as tightly as the master db files.
I don't have any scripts accessing the slave db files. Its purely for
security standards compliance.  It is to check off the checkbox that say
that certain files are owned by certain users/groups and protected with
certain permissions. I need to upgrade to BIND 9.3.1 or better, anyway,
and this is another reason why I should do that. 

Thanks!
jwc

-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
Behalf Of Chris Thompson
Sent: Tuesday, March 18, 2008 3:04 PM
To: Bind Users Mailing List
Subject: Re: Slave db file permissions

On Mar 18 2008, Kevin Darcy wrote:

>Cherney John-CJC030 wrote:
>> I apologize if this has already been answered in the archives or in a

>> FAQ. My searches did not discover anything.
>>  
>> How do I set permissions on the slave db files? The /etc/named.conf 
>> file is updated when a new slave is added to the system, then the 
>> named process takes over and does the zone transfer to get the new
slave file.
>> The slave files aren't protected as tightly as the master files are. 
>> Is there a named.conf zone option I can use? (I didn't see one in my 
>> BIND
>> books.) Is there a command line option on the named process, like
-u/-g?
>> (I didn't see anything in the man pages.) Is it handled entirely by 
>> the umask of the account running the named process?

Esssentially, yes. BIND 9.x doesn't alter the umask it is started with,
and since 9.3 it has created files with permissions 0666&(~umask).

>A better question is: why do you care? You and any scripts that you 
>write shouldn't be looking at the contents of the slave files, since 
>they could be in flux at any given point in time. Think of them as 
>being "private" to the instance of named that is running. If you want a

>dump of a particular zone, do a zone transfer from the nameserver
instance.

I think that's a bit harsh in the absence of information about why the
OP wanted to control the permissions. There are at least two good
reasons. 

First, he may want access to them for debugging purposes. Before BIND
9.3 [this was the change 1267 that Mark Andrews refers to] the files
were created with permissions 0600, which could be quite a nuisance if
one wanted such access as a user other than that BIND was running as.

Second, he may be concerned to protect the zone file contents from other
users with accounts on the nameserver machine, while BIND is configured
to refuse zone transfers for them.

>Same thing applies, generally speaking, to master files for Dynamic 
>Update-enabled zones, by the way: you shouldn't be looking at the raw 
>files. Recent versions of named and rndc understand the "freeze" and 
>"thaw" commands, but "freeze" causes all Dynamic Updates to be 
>suspended for the duration, so it's not appropriate in a lot of Dynamic

>Update environments.

Pretty much the same remarks apply in this case, I think.

--
Chris Thompson
Email: cet1 at cam.ac.uk