Clearing the cache is expensive; if this chain of events will only affect 'developers', that's not ideal but tolerable. But if it'll affect average users we should really try to avoid clearing the cache.
I haven't thought this through very far, but I wonder if we can do a better job solving this if we store a hash of all the input used to generate a binary cache file. We could use a Merkle tree if we wanted to avoid recomputing hashes of repeatedly #included files. (That'd be an optimization far easier to implement if the parser loads a directory of policy itself...) I'm thinking these time-based markers just aren't a good fit for us. Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1350673 Title: System policy cache may become stale after a system image update Status in “apparmor” package in Ubuntu: Triaged Bug description: The system policy cache, in /etc/apparmor.d/cache, may become stale if a certain sequence of events occur at the correct time. 1. Ubuntu developer modifies a profile and uploads a new apparmor package 2. New apparmor package, with an updated profile, is used to build a new system image 3. System policy cache on user's system gets regenerated 4. User applies image update After 4), the timestamps on the files in the user's system policy cache will be newer than the timestamps on system profiles. The parser will not be able to detect that it ought to regenerate the policy cache so it will load the cached, but stale, binary policies. This can result in unexpected AppArmor denials if, for example, the apparmor package update loosens the confinement. On the flip side, it can result in a looser than expected confinement if the update further restricts confinement. The fix is to update the apparmor.conf upstart job to call clear_cache() if the apparmor package has been updated since the last time the job was invoked. Additionally, we may want to update the parser itself to manually set the mtime of a generate binary cache file to the earliest mtime seen while compiling the profile (this includes the mtime of the profile itself as well as any #include's). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1350673/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp