working around kerberos coredumps (ITS#268)

[benno@columbia.edu]

Full_Name: Benn Oshrin
Version: 1.2.6
OS: Solaris 7
URL: http://www.columbia.edu/~benno/libraries-libldap-open.diff
Submission from: (NULL) (128.59.39.90)


I've created a workaround for the kerberos dumping core problem described in
ITS #109 & #241.  The diff is provided at the URL specified.  Note that this
workaround is probably not something you want to incorporate into the
distribution, but is probably useful as a guide to the underlying problem.

In order for kerberos binding to work, the client needs to know the name of
the host it is talking to.  In order to reliably obtain this information, the
connection over which the session will take place must already be established.
Consider the case where the user specifies the hostname "ldap", but ldap is
actually a pool of servers, "ldap1" and "ldap2".  You must know whether to
get a ticket as "ldapserver.ldap1" or "ldapserver.ldap2", and you can only
know this after the connection is open, and further you must then use that
connection for the ldap session since closing and reopening the connection
may connect you to the other host.

Calling ldap_init does not establish a connection at all, and so in calling 
ldap_bind immediately afterwards, the "krbinstance" variable used by 
ldap_get_kerberosv4_credentials is NULL, since this is set after the
connection is opened and, at the time get_credentials is called, no connection
has been opened.  Dereferencing this NULL pointer causes the coredump.

A bit more clearly, in the following order of execution, the kerberos bind and
get_credentials should come at the end, not in the middle.

 ldap_init
 ldap_bind_s
 ldap_kerberos_bind_s
 ldap_kerberos_bind1_s
 ldap_kerberos_bind1
 ldap_get_kerberosv4_credentials
 ldap_send_initial_request
 open_ldap_connection

The workaround in the diff file simply calls a modified version of ldap_open
when ldap_init is called.