[apparmor] dbus/pair address rule encoding

[John Johansen]

On 05/09/2013 12:18 PM, Christian Boltz wrote:
> Hello,
> 
> Am Donnerstag, 9. Mai 2013 schrieb John Johansen:
>> On 05/09/2013 07:16 AM, Christian Boltz wrote:
>>> Could we just switch it to the way that is also used for send?
>>> I'd propose
>>>
>>>     dbus name=sender.com -> name=receiver.com receive,
>>>
>>> Advantages are:
>>> - we can keep the arrow
>>> - same order for send and receive (s/receive,/send,/ and you have
>>> the
>>>
>>>   rule for the sending program)
>>
>> Well this doesn't fix the syntax because we have
>>
>>   dbus name=receiver.con acquire,
> 
> Changing that to
>     dbus -> name=receiver.con acquire,

this looks funny to me we aren't going to transferring or other wise
doing anything at another end we are aquiring/binding a local well
known address

> wouldn't hurt, even if it isn't really needed for aquire (IIRC for 
> aquire the sender can't be specified, right?)
> 
>>   dbus name=receiver.com -> name=sender.com send,
>>   dbus name=receiver.com -> name=sender.com (send, receive),
> 
> That also looks strange ;-)
> 
perhaps its the receiver.com/sender.com format I think we may
largely be arguing the same thing. ie what is your view of
sender and receiver in the transaction.

> I'd make that
>     dbus name=sender.com -> name=receiver.com send,
>     dbus name=sender.com -> name=receiver.com (send, receive),
> 
>>   dbus -> name=sender.com receive,
> 
> What about
>     dbus name=sender.com -> receive,
> 
>>   dbus name=receiver.com receive,
> 
> That should be
>     dbus -> name=receiver.com receive,
> 
> In general, I'd say the arrow _must_ be specified if sender and/or 
> receiver are specified. This might add some bytes to the profile, but 
> makes it very clear what is meant.
> 
>>   dbus receive,
> 
> That's the only case that should be allowed without an arrow.
> 
> To sum it up, IMHO the syntax should be
>     dbus SENDER -> RECEIVER ACTION,
>     dbus SENDER ->          ACTION,
>     dbus        -> RECEIVER ACTION,
>     dbus                    ACTION,
> 
> Sorry for not noticing the (IMHO) wrong parameter order earlier! 
> I hope it's not too late and/or difficult to change it ;-)
> 

sorry I don't see this as any different than what we had. It just
flips the problem from receive being strange to send being strange

also lets get away from sender/receiver for a moment because that
can actually be confusing.

Lets look at it as local (subject) address and remote/peer address

profile subject {

  dbus name=well.known.address acquire,

  dbus name=well.known.address receive,  #subject can receive messages on this well.known.address

  dbus -> name=a.peer.address send,      #subject can send to a peer/remote process using the well known address a.peer.address

  dbus -> name=a.peer.address receive,   #subject can receive a message from a peer/remote process that sent from its a.peer.address
                                         # this case is unusual

}

note that send atomically gives permission to receive a reply, just not to receive arbitrary new messages

the unusually case is the one that tyler pointed out as problematic, and I'm not sure it really is but I would like to get this right


}