[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.
> 
If that is the only reason, I think we can fix that rather easily now.
I propose that we use the name and attachment.

If a name is specified we just use it, otherwise we autogenerate use
the provided name with the variable as the name and expand it into
an alternation for the attachment.

ie.
@{bar} = one two

/foo/@{bar} { }

becomes a profile with the name /foo/@{bar} and the attachment becomes
/foo/{one,two}

alternately we could give the profile a literal text string of the
attachment regex.

>> 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?
> 
hrmm good question.  The namespace is integral to both the name and the
attachment.  That is the name is only valid in the namespace and so is
the attachment.

The original way the namespace was done was it is basically a prefix
of the name.

:namespace1: foo

I believe the parsing is actually responsible for the current form but
that it can be cleaned up more and the space between the namespace and the
name could be eliminated, or made optional.

so I was just trying to extend this format.  I am not entirely happy with
the current namespace specification.  And am more than willing to break
it, as people aren't using it yet.

How would you see namespaces being specified?

> What are you trying to solve or drive toward with this?
> 
>> profile default /** { }
>> profile :namespace: foo /bar { }
>> profile /foo//bar /** { }
>> profile /foo {
>>    profile named /** { }
>> }
>>
>> Signed-off-by: John Johansen <john.johansen at canonical.com>
>> ---
>>  parser/parser.h        |    1 +
>>  parser/parser_alias.c  |   10 ++++++++--
>>  parser/parser_policy.c |    2 ++
>>  parser/parser_regex.c  |    7 +++++--
>>  parser/parser_yacc.y   |   18 ++++++++++++++----
>>  5 files changed, 30 insertions(+), 8 deletions(-)
>>
>