CERN

Bad boy, AppArmor!

So, I’ve been setting up BIND in a redundant system. However, for some reason, the slave wasn’t able to write the files for the slave-zones, even though the folders had correct permissions (even /tmp/ didn’t work). After a while, and some Googling, it turns out that AppArmor was in effect; it basically lets you set rights for software _after_ it’s been loaded, so that it’s only able to write to/access specific folders. Someone claims this is a better solution than to chroot it — but, ehr, I don’t know. Here’s part of the config for AppArmor that’s relevant to BIND;

/etc/apparmor.d/usr.sbin.named:  # /etc/bind should be read-only for bind
/etc/apparmor.d/usr.sbin.named:  # /var/lib/bind is for dynamically updated zone (and journal) files.
/etc/apparmor.d/usr.sbin.named:  # /var/cache/bind is for slave/stub data, since we're not the origin of it.
/etc/apparmor.d/usr.sbin.named:  # See /usr/share/doc/bind9/README.Debian.gz
/etc/apparmor.d/usr.sbin.named:  /etc/bind/** r,
/etc/apparmor.d/usr.sbin.named:  /var/lib/bind/** rw,
/etc/apparmor.d/usr.sbin.named:  /var/lib/bind/ rw,
/etc/apparmor.d/usr.sbin.named:  /var/cache/bind/** rw,
/etc/apparmor.d/usr.sbin.named:  /var/cache/bind/ rw,

So, the issue has been resolved, and BIND is running fine in a redundant setup now.