On 2013-05-09 15:15:50, Seth Arnold wrote: > On Thu, May 09, 2013 at 03:08:35PM -0700, John Johansen wrote: > > it depends how you look at it. To me it is changing the meaning of -> > > of course I am now convinced that -> is just wrong and we need different > > syntax, because -> just seems to have too many potential different > > interpretations that could cause confusion > > Or, we do a bit of jujitsu and -use- the meanings of -> as people seem > to want to read it: do away with the word-based permissions. > > Stick with me :) > > dbus [address spec] acquire, # unchanged > dbus [address spec] -> [address spec], # unidirectional > dbus [address spec] <- [address spec], # unidirectional > dbus [address spec] <-> [address spec], # bidirectional > > This does have a downside that identical rules could actually be written > in two different ways: > > dbus name=foo.org.sender -> , > dbus <- name=foo.org sender, > > -or- > > dbus -> name=foo.org.receiver, > dbus name=foo.org.receiver <- , > > But if the arrows are so strongly tied to the direction information > flows, we could just use it, and .. ignore the send and receive > permissions entirely. > > We'd want to keep the implicitly added "you get to receive replies to > the messages you send", of course. That's just too useful to get rid of. > > So? Eh? :)
I'm all for making the arrows match their meaning when read, but I don't like the idea of arrows pointing in different directions (such as <-). Also, DBus messages are sent from a connection. They are received on a connection with a certain path, interface, and member name. This asymmetry makes the bidirectional arrows confusing when the path, interface, and/or member name are specified in the rule. > > I'll take my MacArthur grant now, please. :) :) Tyler
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
