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 _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
