[apparmor] [PATCH 09/36] apparmor: fix fs extry display for default profile

[John Johansen]

On 05/08/2013 05:48 PM, Seth Arnold wrote:
> On Wed, May 01, 2013 at 02:30:54PM -0700, John Johansen wrote:
>> The default profile needs its replaced by information set as its on
>> the profile list and will have an fs interface (and the fs interface
>> files require a valid replacedby).
>>
>> Signed-off-by: John Johansen <john.johansen at canonical.com>
>> ---
>>  security/apparmor/policy.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/security/apparmor/policy.c b/security/apparmor/policy.c
>> index 333cbb7..a7e6bd9 100644
>> --- a/security/apparmor/policy.c
>> +++ b/security/apparmor/policy.c
>> @@ -731,6 +731,9 @@ struct aa_profile *aa_setup_default_profile(void)
>>  
>>  	profile->ns = aa_get_namespace(root_ns);
>>  
>> +	/* replacedby being set needed by fs interface */
>> +	rcu_assign_pointer(profile->replacedby->profile,
>> +			   aa_get_profile(profile));
>>  	__list_add_profile(&root_ns->base.profiles, profile);
>>  
>>  	return profile;
> 
> Will aa_get_profile(profile) here cause an inability to ever free the
> profile, say in case it is replaced?
> 
not if the profile gets replaced. The replacement causes the replacedby
field to be updated thus breaking the cycle, and enabling the profile
to be freed when it is no longer used

> I know this whole area is drastically changed in a later patch, but if
> this is going to be part of a bisectable kernel tree, it'd be nice if
> this wasn't terribly leaky. :)
> 
indeed, you might be happy to know I have been running these with lots
of debug configs and other debug bits have got to a point where I am
not detecting leaks

> This patch might profitably be merged with an earlier patch; it looks
> like a necessary bugfix for something earlier.

yes its one of the bug fix patches that I mean to fold in. Admittedly
I have been inconsistent on whether I just refresh the original patch
or create a bug fix patch for it.