Implementing preauthentication using loadable modules

[Ken Raeburn]

On Oct 2, 2006, at 20:09, Kevin Coffman wrote:
> The load-time hook is through the use of
> "__attribute__((constructor))" or something else that I'm missing?
>
> Use of "__attribute__((constructor))" seems to work, so it looks like
> that or whatever I'm missing should be sufficient.

That's the core of it on gcc configurations, but it's macroized all  
to heck so that (1) we can do something for non-gcc platforms with  
the same coding conventions, just different macro expansions, and (2)  
checking for errors during initialization is part of the interface.

In include/k5-platform.h we define macros MAKE_INIT_FUNCTION,  
MAKE_FINI_FUNCTION, CALL_INIT_FUNCTION, and INITIALIZER_RAN.  The  
first two are used to specify which functions are your init/fini  
functions.  (They may or may not define some data structures, and/or  
re-declare your function.)  CALL_INIT_FUNCTION gets you the error  
return value from the init function -- and if the constructor  
attribute or DllMain approaches aren't used, it may call the function  
via pthread_once or equivalent.  So you invoke it in any function  
that cares that initialization worked, and can be called without  
CALL_INIT_FUNCTION having been invoked by some other function.   
INITIALIZER_RAN can be tested in the fini function to see if the  
initializer completed without error.  (Doing that as part of this  
framework would've made it *ahem* messy.)  And for performance  
reasons (application start-up time), we prefer the delayed  
initialization by default.

Because on some platforms the init/fini function specification is a  
linker option, not a compiler extension, you also have to provide the  
names in the Makefile when linking.

The Windows case isn't handled cleanly, but we don't have general  
plugin support for Windows right now anyways.

There is one other issue I noticed while hacking on the KDC-location  
plugin (the Python-script sample one); if your plugin loads libraries  
and executes code that depends on having the symbols of those  
libraries available via dlsym, and the tree is configured to do load- 
time initialization rather than pthread_once style delayed  
initialization, it may not work right.  Remember that this invocation  
is part of the library loading process, and the invocation is  
happening from within the dlopen call loading the plugin, so it makes  
sense that the symbols aren't available yet.

Ken