On Fri, Jun 05, 2015 at 03:24:23PM -0700, John Johansen wrote: > Currently the cache file has its mtime set to its creation time, but this > can lead to cache issues when a policy file is updated separately from > the cache file so that is possible a policy file is newer than the > what the cache file was generated from but still fails the comparison > because the generated cache file has a newer timestamp. > > Signed-off-by: John Johansen <[email protected]>
So I think this is still problematic in Ubuntu given how the
/etc/apparmor.d/local/ includes are implemented; they are generated
by dh_apparmor at package postinst time iff the local/ include file
doesn't already exist. This means the generated include gets an mtime
of the package install, and therefore so will the cache file.
Consider the sequence of events for package foo:
(1) foo version n+1 is built with a policy update for foo
(2) foo version n is installed
+ /etc/apparmor.d/local/foo gets an mtime of (2)
+ therefore /etc/apparmor.d/local/foo also gets an mtime of (2)
(3) foo is upgraded to version n+1
+ mtime of foo's cache file (2) is still newer than the policy
mtime for foo (1), so the cache blob is used (incorrectly).
+ even if we required the mtime to be exactly the same, the cache
blob would still be (incorrectly) used (unless we recorded
the mtime for all files), because the local/foo file is the
most recently updated policy element for foo.
But it's possible I might be confused.
--
Steve Beattie
<[email protected]>
http://NxNW.org/~steve/
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
