On 06/11/2013 03:04 PM, Jamie Strandboge wrote: > On 06/11/2013 04:41 PM, Tyler Hicks wrote: > > ... > >> As a side note, one thing that I'm not real happy about is the asymmetry >> of send and receive rules. >> >> When writing a send rule, it doesn't make sense to have a path, >> interface, or member specified in the subject address grouping. >> >> When writing a receive rule, it doesn't make sense to have a path, >> interface, or member specified in the peer address grouping. >> >> This is because you simply send a message through your connection, which >> only consists of a connection name and a connection label. When you >> receive, you receive messages according to the path, interface, and >> member. >> >> So, a rule like this wouldn't really translate to anything that made >> sense: >> >> dbus bus=session subj=(path=/org/gnome/ScreenSaver >> interface=org.gnome.ScreenSaver) >> peer=(path=/com/canonical/indicator/session/session >> interface=com.canonical.indicator.session) (send receive), >> >> But these two rules do makes sens: >> >> dbus bus=session subj=(path=/org/gnome/ScreenSaver >> interface=org.gnome.ScreenSaver) receive, >> dbus bus=session peer=(path=/com/canonical/indicator/session/session >> interface=com.canonical.indicator.session) send, >> >> If we distill that down a little bit, it means that the only subj >> conditionals that make sense with send are name and label and the only >> peer conditionals that make sense with receive are name and label. >> >> It seems like we should be able use that to come up with a syntax that >> is simpler, but I haven't been able to think of one. >> >> This isn't a blocker and we shouldn't spend much time on it, but if a >> light bulb flipped on for anyone while reading that, I'd love to hear >> their idea. >> > > I see what you are saying but we need all of subj with receive and all > of peer with send, so trying to come up with a syntax to accommodate > subj-only, peer-only and a reduced subj/peer seems rather complicated (I > couldn't come up with something else either). The parser is in a > position to warn/fail on subj/peer combinations that don't make sense > though-- maybe that is a reasonable compromise? >
so I agree that dealing with this asymmetry at the syntax level is the wrong place. It will needlessly complicate the syntax, and is the type of check that is handled by a semantic check. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
