[apparmor] [PATCH] fix rc.apparmor.functions

John Johansen john.johansen at canonical.com
Tue Mar 15 22:21:23 UTC 2011

On 03/15/2011 03:09 PM, Steve Beattie wrote:
> On Tue, Mar 15, 2011 at 02:49:14PM -0700, John Johansen wrote:
>> On 03/15/2011 05:10 AM, John Johansen wrote:
>>> The following patch from pld linux is missing from the AppArmor 2.6 release
>> Forgot to add nominated for 2.6.1
> ACK'ed for both trunk and 2.6.1
> Though I have to ask, is this chunk
>>> --- rc.apparmor.functions.org	2010-03-17 21:06:13.768595265 +0100
>>> +++ rc.apparmor.functions	2010-03-17 21:08:34.122087900 +0100
>>>  	retval=0
>>>  	#the list of profiles isn't stable once we start adding or removing
>>> -	#them so stor to tmp first
>>> +	#them so store to tmp first (in reverse order so hat profiles are removed first)
>>> -	sed -e "s/ (\(enforce\|complain\))$//" "$SFS_MOUNTPOINT/profiles" | sort >"$MODULE_PLIST"
>>> +	sed -e "s/ (\(enforce\|complain\))$//" "$SFS_MOUNTPOINT/profiles" | sort -r > "$MODULE_PLIST"
>>>  	cat "$MODULE_PLIST" | while read profile ; do
>>>  		echo -n "$profile" > "$SFS_MOUNTPOINT/.remove"
>>>  		rc=$?
> to cope for the fact that it used to be required to unload hats
> separately (when they were moved in in-kernel structures from
> being internal to a profile to external), and that now the kernel
> no longer requires this as it unloads hats at the same time as the
> parent profile?
Well yeah it because we auto unload the children profiles when
the parent is removed now.  The parent gets removed (and all its
children) and then the iniscript proceeds to try and remove the
children, getting failures that it couldn't find the profile, and
those failure messages get spewed out.

The only other solution I can come up with is making the adding of
children profiles to the list conditional on values in the features

Well or just not supporting older versions of the module which is
something I don't think are ready to do yet.

More information about the AppArmor mailing list