View Single Post
Old 24th December 2008, 17:39
docfx docfx is offline
Junior Member
Join Date: Dec 2008
Posts: 8
Thanks: 0
Thanked 0 Times in 0 Posts
Default but...

While I appreciate your views/opinion on AppArmor, the problem started w/ chrooting bind. I did, indeed, follow the steps exactly by stopping and purging AppArmor from the system.

With AppArmor purged AND later w/ it re-installed (w/ the appropriate lines added to the AppArmor named profile - at NO point did I get any error suggesting it was related to AppArmor ie:
... kernel: [ 9136.933011] audit(1206428817.898:3): operation="inode_permission" request_mask="r::" denied_mask="r::" name="/var/lib/named/etc/bind/named.conf" pid=11825 profile="/usr/sbin/named" namespace="default"
However, under both scenarios, I only obtained syslog errors directly related to and fixed by assigning 755 permissions to the chrooted directories created in step #13, page #4 of the tutorial (specifically those in /var/lib/named/... ) In ferreting thru the various threads, it seems an equal number trying the tutorial, run into either the AppArmor errors OR the same Bind9 permission errors, ie:
... named[11824]: starting BIND 9.4.2 -u bind -t /var/lib/named
... named[11824]: found 1 CPU, using 1 worker thread
... named[11824]: loading configuration from '/etc/bind/named.conf'
... named[11824]: none:0: open: /etc/bind/named.conf: permission denied
... named[11824]: loading configuration: permission denied
... named[11824]: exiting (due to fatal error)
Which is why I posted the permission issues I found on a virgin install.

Bind9 failed in the same way when the server was gutted, AppArmor stopped/purged, and rebooted as when AppArmor was re-installed and correctly configured - so I'm not thinking it is/was a AppArmor issue.

AppArmor may well get purged before I'm done setting up the server completely, but I don't think the issues w/ chrooting bind can all be dismissed as AppArmor as the sole culprit.
Reply With Quote