kdb ldap back end

[Ken Raeburn]

On Mar 17, 2006, at 09:02, Praveenkumar Sahukar wrote:
>>> A separate library can be derived out of the ldap database plug-in.
>
>>> My guess is, with the separate library, ldap-util program need not
> link to the ldap database plug-in. am i right ?

Right.  Both the plugin and the ldap-util program should just link  
against the separate library.  (Well, and some of the main Kerberos  
libraries, as needed.)

>>> We can write some wrapper routines that in turn will call DAL apis
> for LDAP (like krb5_ldap_put_principal).
>>> The wrapper functions will become part of the plug-in and will be
> called by DAL.
>>> The DAL apis (like krb5_ldap_put_principal) can be moved to the
> separate library
>>> and ldap-util can call the DAL apis directly. This way ldap-util
> will not have to link to plug-in.

As it happens, I've already written wrapper functions.  I'd  
previously modified the KDB plugin API to assume that the plugin code  
is thread-safe (which I think we eventually want to be the case for  
most if not all DAL plugins), rather than conditionally doing locking  
in the caller based on flags, so for now I've taken the brute-force  
approach of creating a mutex in the plugin and replacing every  
function pointer in the table with a pointer to a helper function  
that locks the mutex.  It should handle a multithreaded KDC okay,  
though I'm not 100% sure it's right for opening multiple databases at  
once; I plan to check that part over again.

So the functions like krb5_ldap_put_principal can go into the shared  
library, and the helper functions can stay in the plugin (which I  
think would be down to one .c file).

Ken