Package: dh-apparmor Version: 2.12-4 Severity: minor Hi,
Christian Boltz: > - dh_apparmor loads profiles at package install time even if > apparmor.service is masked > You might want to open a new bug for for dh_apparmor. Indeed, it feels wrong. For upgrades: as a user, if I've made it so that usr.bin.evince is not loaded on boot (by disabling apparmor.service), it feels wrong that Evince suddenly becomes confined after an upgrade. I guess dh_apparmor should update the profile in the kernel upon upgrades only when the profile was already loaded. For initial installation: it feels inconsistent that dh_apparmor loads a profile when installing a package, while we won't load that profile again during next boot. Now, I'm pretty sure that in most cases, a user who has disabled or masked apparmor.service actually meant "I don't want to use AppArmor on this system". And then this dh_apparmor bug will likely be the first of a series of surprising behaviour: other system components, such as libvirt/lxc/etc., still can — and likely will — load and enforce some profiles themselves. So my point is: let's not make users believe that disabling/masking apparmor.service is a supported way for disabling AppArmor. It's not and I believe we can't ever realistically promise to support it. So I've documented how to disable AppArmor on Debian: https://wiki.debian.org/AppArmor/HowToUse#Disable_AppArmor I believe it will help limit the impact of this bug, which is why I'm giving it minor severity. Cheers, -- intrigeri
