[Telepathy] Port access control for Stream Tubes

[George Goldberg]

H,

I'm having some trouble with understanding/using Port based Access
Control with Stream Tubes on the offering end of the tube.

First, my understanding of how Port based Access Control is supposed
to work at the offering end of the tube. Please correct me
if any of this is wrong, since that would hopefully answer the rest of
my questions as a side-effect.

Firstly, for a single Stream Tube, gabble will make a separate
connection to the given TCP port on the offered service
for each Telepathy Contact who accepts the Stream Tube. Furthermore,
gabble will emit the NewConnection signal prior to
making each connection to the TCP port of the service, and the signal
parameters will contain the port from which gabble
is going to connect. This means that, in order to prevent unauthorized
access to the service, I can reject any connections
that did not come from a port that I was previously notified of in a
NewConnection signal.

However, there is a race condition with this which is making it rather
complicated for me to implement in a satisfactory way.
Consider the following scenario:

I have used my Instant Messaging client to offer to share my desktop
with Mike and Paul, however, I obviously don't want anyone else
to gain access (including other people logged on to the same
computer), so I'd like to have a pretty solid access control method.
Port based access control to the service seems to be the best
candidate from the supported methods.

I offer the tube to Mike and Paul.

Mike accepts the tube, which leads gabble to make its first connection
with my application. However, my application already started listening,
and because it receives the request to connect from gabble on the socket
before it receives the NewConnection signal over DBus it rejects Mike's
connection because the port from which gabble connected was not in the
approved list.

A fix I have had suggested to me for this is the following: do not add
the socket to the event loop
until the NewConnection signal is received from DBus. This works fine
if the tube is only offered to one
Contact, however:

Mike is stil connected, but Paul now accepts the tube too, resulting
in another connection attempt
to my app from gabble, on a different port. This time, the socket has to
be in the event loop already because someone else is already connected to it, so
I can't use the previous fix. However, I still receive the NewConnection signal
from gabble after the connection on the socket, so it gets rejected
again, because
the port is not already in the approved list.

Are my assumptions about how Stream Tubes work broken, and if not, how
should I avoid this issue?

--
George Goldberg