apparmor_parser fails to consider its own time stamp when determining if profile cache is stale

Bug #731184 reported by John Johansen on 2011-03-08
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AppArmor
Medium
Unassigned
2.6
Medium
Unassigned

Bug Description

If the apparmor_parser is updated (outside of current packaging), when doing profile loads it will use the existing cache of compiled profiles, instead of forcing a recompile on profiles.

This can cause apparmor to load bad policy if the parser contains a bug fix for the previous version of the parser.

This can be worked around in packaging by invalidating the cache and forcing a profile reload when the parser is upgraded.

Kees Cook (kees) wrote :

The Ubuntu packaging for the parser already does this.

For a more air-tight solution, the parser version should likely be included in the future cache metadata.

John Johansen (jjohansen) wrote :

Right this isn't a bug that will affect Ubuntu with the current way things are packaged. I don't even think it is something that needs to be considered in the metadata, the parser can just look at its own timestamp and compare it to the cache file, just like it is already doing for the source files.

Steve Beattie (sbeattie) on 2011-03-08
Changed in apparmor:
status: New → Triaged
importance: Undecided → Medium
milestone: none → 2.6.1
Steve Beattie (sbeattie) wrote :

Fixed in commit http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/revision/1679 (pre 2.6 branching from trunk, but post 2.6.0 release).

Changed in apparmor:
status: Triaged → Fix Released
milestone: 2.6.1 → none
Steve Beattie (sbeattie) wrote :

AppArmor 2.6.1 was released.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers