On 06/30/2011 10:04 AM, John Dennis wrote:
On 06/29/2011 04:58 PM, Rob Crittenden wrote:
John Dennis wrote:
On 06/29/2011 03:08 PM, Rob Crittenden wrote:
If we set the callback before calling connect() then if the connection
tries a network family type and fails, it will try other family types.
If this happens then the callback set on the first socket will be lost
when a new socket is created. There is no way to query for the callback
in an existing socket.


I'm tempted to NAK this. In part because I don't really understand why
it works, but more because nsslib.py doesn't seem to be handling
addresses, sockets and connections correctly. At first glance it appears
to only create a new socket when switching families. I also don't
understand the logic behind the family code.

It works like this:

- We create an NSSConnection() with automatically gives us an SSL socket
- We can add the callback here but if the connection fails a new socket
will be created. There is no way I can see to find the callback call. I
don't think this is even part of the C API so this isn't a deficiency in
python-nss.
- The connect() call just makes a network connection. NSS doesn't do
anything until the first bit of data gets written to the socket so we
can set the callback after the connection is completed.

The default family is UNSPEC which is treated as IPv4.

But most importantly it seems to shutdown NSS every time you make a
connection. What happens when you want more than one simultaneous
connection?

NSS is still very limited regarding having multiple NSS databases open
at once. This code is meant to allow one to switch databases. Runnning
within Apache (and our framework) the shutdown will fail because things
in the database are in use, so this is a bit of a no-op. It is really
just needed in the installer where things are done serially, so again no
problem.


Maybe we need to open a ticket to review nsslib.py.


A review of nsslib would't hurt, it has had a lot tacked on since
inception, but we'd still have to deal with multiple databases, family
failover, etc. I'd rather do that as a next step.

rob

O.K. agree with all above.

ACK

Tested.  It fixes the install on an IPv6 only system.  Pushed to master.

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to