deny send_destination policy also blocking signals ?

[Havoc Pennington]

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
> expect.
> 

There's a paragraph in the man page that's intended to clarify this, 
probably unsuccessfully.

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" 
(bus 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[1] 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.

Havoc

[1] OK technically it should be "connection" not "process" if a process 
opens two connections they are treated separately