deny send_destination policy also blocking signals ?
hp at redhat.com
Thu Jun 22 16:57:09 PDT 2006
Sjoerd Simons wrote:
> I've did some little more testing to get the semantics clear for myself, so for
> signals that don't have an explicit destination basically all destinations
> match (as long as their applicable to the program).
> So say we have something like this (and the program owns those 2 names):
> <deny send_destination="my name 0">
> <allow send_destination="my name 1">
> Then methods/signals to "my name 1" are allowed, but also signals without an
> explicit destination. But if those two rules would be swapped signals without
> an explicit destination would be denied. Which is a side-effect i didn't
There's a paragraph in the man page that's intended to clarify this,
The key is that send_destination matches the _owner_ of the name, not
the name the message specifies. Otherwise you would have different
security depending on the name you used for routing. In other words the
"firewall" (policy) is on the "computer" (process) not the "domain name"
So when you deny to name 0 then allow to name 1, and the same process
owns the two names, the rules cancel out and do nothing whatsoever.
If you allow to name 1 then deny to name 0, then you've denied
everything going to that process for as long as the process owns name 0.
Note that anything like this produces kind of a funky race condition
(the process has to ask for name 0 then name 1, with an interval in
between, during that interval only one of the rules will apply).
Anyway, the confusing part is that some allow/deny matching is done on
the messages themselves (e.g. method names), but the sender/recipient
rules have to do with which process the bus is sending to.
The above is "how I believe it is supposed to work," it's always
possible there are bugs of course.
 OK technically it should be "connection" not "process" if a process
opens two connections they are treated separately
More information about the dbus