On Sun, 2017-11-05 at 12:21 +0100, intrigeri wrote: > Hi, > > Ben Hutchings: > > My understanding was that enabling AppArmor shouldn't do very much > > until a policy is loaded (which it won't be if you don't install the > > userland tools). As you've found, that isn't entirely correct. > > Let me clear a potential misunderstanding: > > - It *is* correct that the AppArmor LSM doesn't do very much if no > policy is loaded, i.e. if the apparmor package is not installed. > > - The only report I've heard of so far of breakage caused by AppArmor > being enabled in the kernel by default, on systems that have no > AppArmor policy loaded, is #880490. That bug was not about AppArmor > denying anything, but about systemd trying to switch to an AppArmor > profile that was not loaded (precisely because the apparmor package > was not installed). Thankfully that bug has been fixed very > quickly. According to codesearch.debian.net it was the only > instance of this problem. I'm sorry I didn't think of this corner > case initially. > > > Still, I'll bump this back to serious as I don't think we should let > > this into testing yet. > > I think this does not apply anymore, now that the "unrelated" breakage > has been fixed, and the reasons behind it clarified. What do > you think? Yes, I now understand this. I'll add a Recommends: apparmor for the next upload so this broken configuration is less likely to occur. The current unstable version FTBFS on several architectures, so it wouldn't have gone into testing anyway. Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together.
Attachment:
signature.asc
Description: This is a digitally signed message part