[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: "fixing" syncrepl with GSSAPI (MIT kerberos)

Ralf Haferkamp wrote:

most of you probably know the issues with using syncrepl with SASL/gssapi
when built against MIT Kerberos. Is cause of the problem is also well
know. MIT's gssapi implementation will not encode packages for
established connection anymore once the ticket is expired. Once this
happened any connected syncrepl consumer will just hang forever.

I know there have been a lot of discussion in the past on wether
Heimdal's of MIT's approach is correct. And I don't want to start yet
another one. (It seems even that MIT will switch to the Heimdal behavior
with future releases:
http://krbdev.mit.edu/rt/Ticket/Display.html?id=6739 )

But to fixing the problem with current releases seems to be pretty easy.
At least if I didn't overlook something. If we'd just close the syncrepl
connection once the provider fails to send a message to the consumer, we
consumer's retry mechanmis can try to reestablish the connection (this
will succeed once the tickets have be refreshed by some external tool).

The basic functionality is there already it seems. send_ldap_ber() calls
connection_closing() when ber_flush fails (which happens when
sasl_encode() fails because the ticket expired).
The only thing that's missing seems to be to actually close the
connection in the syncprov overlay after syncprov_sendresp() failed. For
that to happened we'd need to export connection_close() to have it
available in syncprov.c.

Did I overlook something? Would anybody object if I'd commit the required

I recall wanting to export connection_close() for syncprov before, but stopping. I don't remember at the moment why, probably it was going to take too much time to figure out the locking order. Go ahead and try if you like.

  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/