BIND less restrictive modes and policy

[Chuck Anderson]

On Mon, Jan 21, 2008 at 04:57:21PM +0100, Adam Tkac wrote:
> On Mon, Jan 21, 2008 at 09:48:53AM -0600, Chris Adams wrote:
> > Once upon a time, Adam Tkac <atkac at redhat.com> said:
> > > - /var/named will be writable and read-only permissions will be set
> > >   per-zone by admin
> > 
> > If the directory is writable, read-only file permissions are
> > meaningless.
> > 
> 
> Maybe but what other solution will be better? I could create separate
> read-only directory inside /var/named (called "masters" for example)
> and put all read-only zones there but I'm not sure if admins will like
> it and use it.

If directory layout changes are necessary, I'd rather that very 
minimal changes be made, but this seems like a good change to make to 
allow having master zone files that aren't writeable by the named 
user.

So I propose to keep the existing directory split and add the masters/ 
subdirectory if and only if it ends up being necessary to change 
permissions on /var/named/ to be writeable by the named process.

I think we should investigate whether using 'directory 
"/var/named/data";' like I mentioned in my other email works first.  
How would people feel about needing full or ../ relative paths in zone 
"file" statements?

I'll test this setup now to see if it helps with coredumps, but I 
don't think this is the root cause of the coredump failure.  I tried 
running BIND in various ways to allow coredumps to work, and even when 
running it as root with SELinux set to permissive it failed to dump 
core.  I think there are problems with the logic of the code that sets 
the Linux Capability bits.