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@xxxxxxxxxx> 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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
