Slave db file permissions

[Chris Thompson]

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