[apparmor] [patch] fixes for LP: #775785, full /tmp reload issue

[John Johansen]

On 08/04/2011 11:47 AM, Steve Beattie wrote:
> Bug: https://bugs.launchpad.net/bugs/775785
>
> Attached is a patch to make the initscript not fail if /tmp is full
> by converting the comm(1) usage on temporary files to an embedded
> awk script. On both Ubuntu and OpenSUSE, a version of awk (mawk in
> Ubuntu, gawk in OpenSUSE) is either a direct or indirect dependency
> on the minimal or base package set, and the original reporter also
> mentioned that an awk-based solution would be palatable in a way that
> converting to bash, or using perl or python here would not be.
>
> I've also attached a patch for the Ubuntu version of the initscript,
> which is distinct from the upstream versions.
>
> In the embedded awk script, I've tried to avoid gawk or mawk specific
> behaviors or extensions; e.g. this is the reason for the call to sort
> on the output of the awk script, rather than using gawk's asort(). But
> please let me know if you see anything that shouldn't be portable
> across awk implementations.
>
> An additional issue that is fixed in both scripts is handling child
> profiles (e.g. hats) during reload. If child profiles are filtered
> out (via grep -v '//') of the list to consider, then on reloading
> a profile where a child profile has been removed or renamed, that
> child profile will continue to stick around. However, if the profile
> containing child profiles is removed entirely, if the initscript
> attempts to unload the child profiles after the parent is removed,
> this will fail because they were unloaded when the parent was unloaded.
> Thus I removed any filtering of child profiles out, but do a post-awk
> reverse sort which guarantees that any child profiles will be removed
> before their parent is. I also added the LC_COLLATE=C (based on the
> Ubuntu version) to the sort call to ensure a consistent sort order.
>
> For the Ubuntu version of the patch, I pulled the libvirt filtering
> out of running_profile_names(), as it meant that on a 'teardown'
> call, libvirt dynamic policies would still be in place, which seems
> like incorrect behavior to me.
>
> This is nominated for both trunk and the 2.6 branch.
>
>
Ugh, I'll agree with the least bad statement below.  My head hurts now

Acked-by: John Johansen <john.johansen at canonical.com>