intrig...@debian.org: > This is about supporting Stretch users who have enabled AppArmor > and run a new kernel, e.g. from stretch-backports.
> Similarly to #879584, let's pin the AppArmor feature set to the one > supported by the Stretch stock kernel, i.e. the one the AppArmor > policy shipped in Stretch works well with. I've tested this: 1. start a Stretch system with the AppArmor LSM enabled and the apparmor package (from Stretch) installed 2. cp /etc/apparmor.d/cache/.features /etc/apparmor/features 3. echo "features-file=/etc/apparmor/features" >> /etc/apparmor/parser.conf 4. reboot 5. everything comes up fine :) Now test the case when one runs a newer kernel on Stretch with a feature set pinned to Linux 4.9's: 6.a reboot on Linux 4.14-rc5 from Debian experimental 7.a everything comes up fine :) Then roll back to the state we were in after step 5 (i.e. running Linux 4.9 with its own feature set pinned) and test the upgrade path to Buster: 6.b copy the 4.14's features file to /etc/apparmor/features 7.b upgrade to my tentative apparmor 2.11.1-1 package; this triggers a policy reload that fails and spits out quite a few error messages (Unable to replace "sanitized_helper". Profile doesn't conform to protocol); but the upgrade succeeds on the dpkg level as the policy reload is not fatal in apparmor.postinst. I think these tests validate the general idea. Cheers, -- intrigeri