kdb ldap back end
raeburn at MIT.EDU
Fri Mar 17 13:51:04 EST 2006
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).
More information about the krbdev