Yes the apparmor_parser should set the mtime of the cache file to be the most recent mtime timestamp of the set of policy files that resulted in the cache files creation. This is something we have been meaning to do for a long time but just never gotten around to it because there always something more important.
I will come up with a patch today -- 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/1460152 Title: apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates) Status in Snappy Ubuntu: In Progress Status in Snappy 15.04 series: In Progress Status in apparmor package in Ubuntu: New Bug description: The apparmor cache gets confused easily on upgrade. Here is what happens: - boot stable, /etc/apparmor.d/cache/usr.bin.ubuntu-core-launcher is mtime of now because we generate the cache on boot - upgrade to edge, /etc/apparmor.d/usr.bin.ubuntu-core-launcher is updated and has the mtime of T (yesterday) when the file was put into the package - on the next reboot the apparmor_parser compares the mtime of the cache/usr.bin.ubuntu-core-launcher (very very recent) with the mtime of the souce usr.bin.ubuntu-core-launcher (much older) -> cache does is *not* re-generate Possible solution: - clear cache on upgrade - make apparmor_parser store mtime of the source file in the header - make apparmor_parser use set the cache file to the mtime of the source file used to generate the cache and re-generate if those get out-of-sync Original description: ---------------------- Rick Spencer ran into the situation that he ended up with a snappy image that gave the following error: """ apparmor="DENIED" operation="mkdir" profile="/usr/bin/ubuntu-core-launcher" name="/tmp/snap.0_pastebinit.mvo_em33Zz/" pid=1092 comm="ubuntu-core-lau" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 """ Running: $ sudo apparmor_parser --skip-cache -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher fixes it. This strongly indicates that the cache has the old content and did not get re-generated on upgrade or image build. I also managed to reproduce this via: 15.04/stable->15.04/edge The image is here: https://drive.google.com/open?id=0B1sb5ymdUGiLa0tUR0pGV3lzR1k&authuser=0 To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1460152/+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
