Difference between revisions of "Projects/Plugin support improvements (first version)"

Revision as of 23:34, 29 January 2010

This page contains some notes about improving the plugin infrastructure, but does not make a specific proposal yet.

Current plugins

We currently have the following plugins:

Future plugins

The following areas are candidates for future plugin support:

Current support infrastructure

In libkrb5support, we have functions to facilitate loading plugins from shared objects. There is a set of functions to load individual plugins from named files and mechglue; these are currently used by the HDB bridge and GSS mechglue:

• krb5int_open_plugin - Create a plugin handle from a filename
• krb5int_close_plugin - Close a plugin handle
• krb5int_get_plugin_data - Retrieve a data object from a plugin handle by symbol name
• krb5int_get_plugin_func - Retrieve a function object from a plugin handle by symbol name

There is another set of functions to scan a list of directories for plugins:

• krb5int_open_plugin_dirs - Create a plugin dir handle from a list of directories and (optionally) filebases
• krb5int_close_plugin_dirs - Close a plugin dir handle
• krb5int_get_plugin_dir_data - Retrieve a list of data objects from a plugin dir handle by symbol name
• krb5int_get_plugin_dir_func - Retrieve a list of function objects from a plugin dir handle by symbol name
• krb5int_free_plugin_dir_data - Free a list of data objects returned by krb5int_get_plugin_dir_data
• krb5int_free_plugin_dir_func - Free a list of function objects returned by krb5int_get_plugin_dir_func

Problem areas

• Every caller of krb5int_open_plugin_dirs specifies either no filebases (e.g. preauth plugins) or a single filebase (KDB plugins). Accepting and processing a list of filebases is probably needless complexity.

• Callers of krb5int_open_plugin_dirs have to know what directories to supply, which means they need to know the krb5 install root as well as the magic plugin area for OS X, and they need logic for reading a profile variable to determine the alternate plugin directory for the test suite (currently only implemented for KDB and preauth plugins).

• In most uses of plugins, we read a data object containing a list of function pointers. This makes it mostly impossible to supply a plugin which works with multiple versions of krb5. If we instead read a function object which we invoked with a version number to retrieve the vtable, it would be possible (though perhaps awkward) to create a shared object which works with multiple versions.

• We are somewhat schizophrenic about how plugins can access krb5 library functionality, and in particular internal symbols. Sometimes we call functions directly, sometimes we make use of a vtable passed into the plugin (e.g. the preauth_get_client_data_proc function), sometimes we use the accessor to invoke internal functions, and sometimes we call APIs or internal functions directly. Ideally we should have a consistent policy with a sound justification.

• When measuring code coverage with gcov, we cannot use shared libraries; this means we need to link in-tree plugins statically into the libraries or programs which load them. We have an ad-hoc method to do this with KDB plugins, but not with other plugin types.

• Administrators have an easier time writing scripts than creating linkable shared objects. In some cases it might yield a better administrator experience to create plugin interfaces via subprocesses than loading shared objects, although in many cases this might not be feasible.

• In some scenarios such as embedded environments, it may be more useful to allow applications to supply plugin vtables via an API (as we do for keytabs and ccaches, though those APIs are not public) than to load them from shared objects in the filesystem.