[apparmor] dbus/pair address rule encoding

John Johansen john.johansen at canonical.com
Fri May 10 17:29:02 UTC 2013


On 05/10/2013 10:22 AM, Jamie Strandboge wrote:
> On 05/10/2013 11:42 AM, John Johansen wrote:
>> On 05/10/2013 08:24 AM, Jamie Strandboge wrote:
>>> On 05/10/2013 09:45 AM, Jamie Strandboge wrote:
> 
> ...
> 
>>> Well, arguably the most consistent would be tweaking Steve's grouping
>>> slightly to have a rule like this (my previous "I don't want commas for
>>> the subject" comment didn't consider subj()):
>>>
>> I'll reiterate just in case people missed it buried in my reply to your
>> other email, the commas in ( ) are optional. In fact the only reason
>> I included support for them was that the original flags=( ) syntax
>> used them and I included them for backwards compat. Of course it also
>> doesn't hurt that it just works when someone is used to writing out
>> a list with commas
> 
> Ok. I didn't think commas would be allowed for the subject. Ie, I
> thought this was not allowed:
> 
>   dbus bus=session, name=..., path=... send,
> 
this isn't allowed

what I was saying is you don't have to us commas in the ( ) grouping
  dbus subject=(bus=session name=... path=.. ) send

> so I didn't like the mixture of allowed/disallowed commas inside/outside
> of peer().
> 
right, so we just don't recommend using commas in the ( ) grouping

>>
>>> dbus bus=... subj=(name=..., path=...) peer=(name=..., path=...) send,
>>>
>> I could live with this too
>>
>>> This is exceptionally clear and consistent with other multi-valued sets,
>>> but is verbose ('subj=(name=...' admittedly looks slightly odd with the
>>> two '='s in close proximity, but I can live with that).
>>>
>> yes the two = in proximity are a little weird
>>
> 
> But acceptable IMO
> 
>>> Still open, but this is my new favorite (let it sink in for a moment and
>>> I think you may agree :).
>>>
>> So I tend to prefer the word being tied to the ( ), but I would be open
>> to using a different symbol than =
>>
> 
> I agree, the word should be tied to the (), and again, '=' is acceptable
> to me and consistent with other multi-valued sets.
> 
> I really am starting to like:
> dbus [<bus>] [subj=()] [peer=()] [<access>],
> 
> cause is consistent within itself too, ie, when specifying 'bus':
>   dbus bus=... subj=... peer=... send,
> 
I have to say that I haven't taken a liking subj= part yet. But I'll give
it some more time, it does have a certain consistency to it
 



More information about the AppArmor mailing list