Quack,
I had a similar problem just now when migrating from
1:9.11.5.P4+dfsg-5.1+deb10u2 to 1:9.16.11-2~bpo10+1.
Aside from the similar permission errors I also had this output:
# aa-status | grep -E '^[0-9]+|named'
34 profiles are loaded.
18 profiles are in enforce mode.
/usr/sbin/named
named
This means there's two conflicting profiles loaded.
Btw `journalctl -k -b0 | grep -F apparmor` does not catch apparmor
messages in my case, but they are available in /var/log/audit/audit.log
(I have auditd installed but no specific rules).
So I looked at the rules:
# rgrep /usr/sbin/named /etc/apparmor*
/etc/apparmor.d/apparmor-profile:/usr/sbin/named {
/etc/apparmor.d/apparmor-profile: /usr/sbin/named mr,
/etc/apparmor.d/usr.sbin.named:profile named /usr/sbin/named
flags=(attach_disconnected) {
/etc/apparmor.d/usr.sbin.named: /usr/sbin/named mr,
I have no idea where apparmor-profile comes from but it's not of my
doing:
# dlocate /etc/apparmor.d/apparmor-profile
bind9: /etc/apparmor.d/apparmor-profile
I did not find in which version it came from though, maybe some previous
bpo; it's dated 2007 and a very basic profile (I can paste it if one
wants to look at it).
A reload of apparmor was not sufficient but this worked:
apparmor_parser -R /etc/apparmor.d/apparmor-profile
rm /etc/apparmor.d/apparmor-profile
apparmor_parser -r /etc/apparmor.d/usr.sbin.named
systemctl restart named
Hope this helps.
\_o<
--
Marc Dequènes
