[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