[apparmor] [PATCH 18/43] apparmor: provide base for multiple profiles to be replaced at once

[John Johansen]

On 02/12/2013 06:14 PM, Seth Arnold wrote:
> On Fri, Feb 08, 2013 at 01:00:54PM -0800, John Johansen wrote:
>>  /**
>> + * __lookup_replace - lookup replacement information for a profile
>> + * @ns - namespace the lookup occurs in
>> + * @new - profile to lookup who it is replacing
>> + * @noreplace - true if not replacing an existing profile
>> + * @old - Returns: pointer to profile to replace (NO REFCOUNT)
>> + * @rename - Returns: pointer to profile to rename (NO REFCOUNT)
> 
> old and rename do appear to be refcounted:

err yes, I believe the comments even say so
>> + * @old - Returns: pointer to profile to replace (NO REFCOUNT)
>> + * @rename - Returns: pointer to profile to rename (NO REFCOUNT)
:)

what is going on is the profile list is holding the refcount, and its locked
so that it can not be changed, so a refcount is held indirectly.

> 
>> ...
>> +	if (r_old)
>> +		*r_old = aa_get_profile(old);
>> +	if (r_rename)
>> +		*r_rename = aa_get_profile(rename);
> 
> 
> 
> 
>> @@ -622,29 +623,40 @@ fail:
>>  /**
>>   * verify_head - unpack serialized stream header
>>   * @e: serialized data read head (NOT NULL)
>> + * @required: whether the header is required or optional
>>   * @ns: Returns - namespace if one is specified else NULL (NOT NULL)
>>   *
>>   * Returns: error or 0 if header is good
>>   */
>> -static int verify_header(struct aa_ext *e, const char **ns)
>> +static int verify_header(struct aa_ext *e, int required, const char **ns)
>>  {
>>  	int error = -EPROTONOSUPPORT;
>> +	const char *name = NULL;
>> +	*ns = NULL;
>> +
>>  	/* get the interface version */
>>  	if (!unpack_u32(e, &e->version, "version")) {
>> -		audit_iface(NULL, NULL, "invalid profile format", e, error);
>> -		return error;
>> -	}
>> +		if (required) {
>> +			audit_iface(NULL, NULL, "invalid profile format", e, error);
>> +			return error;
>> +		}
> 
> I know the message hasn't changed, but it feels like it could be more
> specific about an expected version packet that was not found -- it might
> make future debugging easier to have a more specific message.
> 
yes the message could certainly be improved