BIND less restrictive modes and policy
Chuck Anderson
cra at WPI.EDU
Tue Jan 22 14:26:33 UTC 2008
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.
More information about the fedora-devel-list
mailing list