On Tue, Jan 22, 2008 at 05:04:11PM +0100, Adam Tkac wrote: > > 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? > > This doesn't sound well for me. This will be very annoying. IMO, "annoying" is trumped by "more secure". SELinux is annoying too, but we still use it. I have verified that relative paths work, as well as symlinks from the data/ dir (not that I recommend doing it this way): #ls -l /var/named/data total 4 lrwxrwxrwx 1 root root 9 2008-01-22 09:30 slaves -> ../slaves/ I think we need a new feature in BIND...one where the CWD can stay at /var/named/data regardless of the "directory" option so that zone file paths don't have to be changed--perhaps a new option. > I don't think so. As I wrote in > https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able > to produce core file after setuid when /var/named directory is > writable by named user. This is main reason why I want this directory > writable. It means that you will have always core file when named > gets sigsegv (no additional setup is needed, only writable > /var/named). This change means lower security on the one hand but on > the other hand we will always get core file. Ok, I'll try this. But I don't think we should change the default setup just to be able to generate coredumps at the expense of security, especially if we are still going to require SELinux to be put into permissive mode to make it actually work. We should just document the changes one needs to make to generate coredumps since we already require some changes anyway, i.e.: /etc/sysconfig/named: DAEMON_COREFILE_LIMIT=unlimited sysctl -w fs.suid_dumpable=1 chmod 755 /usr/sbin/named chmod 775 /var/named setenforce 0 service named restart (which of these aren't required?) If we are going to make changes to allow coredumps by default, then SELinux policy should be adjusted to allow this as well because running your system in permissive mode for long periods of time makes it a royal pain to switch back--I had to boot into single user mode with selinux=0 and run "fixfiles restore" manually since rc.sysinit couldn't do it automatically (see https://www.redhat.com/archives/fedora-selinux-list/2008-January/msg00079.html for the problems I had). I just don't think it is a good idea to implement this by making /var/named writeable, undoing the extra layer of security we have for master zone files now. We should find some other way to mitigate this. It's not like coredumps are frequent, and daemons aren't allowed to coredump with our default config anyway... -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
