[apparmor] dbus/pair address rule encoding

Christian Boltz apparmor at cboltz.de
Thu May 9 19:18:38 UTC 2013


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,
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 ;-)

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 ;-)


Regards,

Christian Boltz
-- 
Non-understandable error messages are trademark of someone else, so 
SUSE is not allowed to submit them. ;-))   [Eberhard Moenkeberg in
https://bugzilla.novell.com/show_bug.cgi?id=209354]




More information about the AppArmor mailing list