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
}
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
