Implementing preauthentication using loadable modules
raeburn at MIT.EDU
Mon Oct 2 20:33:39 EDT 2006
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.
More information about the krbdev