touch-packages team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxx>]

That said, if the hash operation was very fast, that would be a useful
improvement going forward (I don't think we could do that for rtm). I do
worry that if we compute hashes for all policy on every boot to see if
we need to recompile, that is going to be more costly for the average
user. What we really need to do is fix parser performance (bug #1350598.
I realize we had a lot of improvements, but we are up to ~4 seconds per
click profile on Touch, and users can easily have 100 or more profiles).

-- 
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