[apparmor] [PATCH 4/5] And the ability to specify the name and attachment of the profile separately. It does not allow for the attachment specification to begin with a variable however since variables in profile names is not currently support this shouldn't be and issue.

[John Johansen]

On 11/29/2010 01:11 PM, Steve Beattie wrote:
> On Tue, Nov 23, 2010 at 01:18:54AM -0800, John Johansen wrote:
>> Add the ability to specify the name and attachment of the profile
>> separately. It does not allow for the attachment specification to
>> begin with a variable however since variables in profile names is not
>> currently support this shouldn't be and issue.
> 
> The reason that variables are not supported in profile names is that
> it would essentially result in multiple profile names attached to a
> single profile, and as you've pointed out, there are some difficulties
> in supporting that.
> 
>> The format of the naming follows the basic guide of the name coming
>> before the attachment but after profile namespace.
> 
> Why after the namespace? Why is the namespace not integral to the name?
> 
Another attempt at answering this,
yes the namespace is integral to the name, however it is currently parsed
as a separate token, so white space is currently allowed between the
namespace and the name.

Whether we want to change that and force the namespace to tokenized
with the name is a different issue that can be discussed.

> What are you trying to solve or drive toward with this?
> 
Trying to provide reasonable handles/abstractions for profiles that
are independent of their attachment.

Eg.  Its easier to deal with the firefox profile than
/usr/lib/firefox-3.6.13/firefox-*bin

it also provides a more stable naming for any rule that contains a
profile name (eg. named profile transitions, change_profile,
ipc rules).