Re: Confused about plugins

On Tue, Oct 25, 2011 at 8:53 PM, Nico Williams <[email protected]> wrote:
> There seems to be two namespaces of plugins: those registered via
> krb5_plugin_register() or loaded via _krb5_plugin_find() on the one
> hand, and those loaded via _krb5_load_plugins() on the other.
>
> What's this distinction about?

I still don't know what the distinction is about, however, I can
characterize the differences between the two plugin systems.

I'll refer to the two systems as "plugins" and "modules".

 - The plugin system allows both dynamic loading as well as statically
linked plugins that register with the plugin system.

 - The plugin system requires that the caller use _krb5_plugin_find()
to find a plugin by name, then invoke it.

 - The module system only supports dynamically loaded modules.

 - The module system provides an interface by which to call all the
modules in sequence: _krb5_plugin_run_f().  The caller provides a
callback that gets the module as an argument, and that callback can
stop the module evaluation by returning something other than
KRB5_PLUGIN_NO_HANDLE.

 - The plugin system doesn't impose any structure on the symbols it
dlsym()s, while the module system does (they must be data symbols
whose value is a pointer to a structure that starts with three common
fields...).  Some plugin uses happen to use data symbols that are
compatible with the module system.

All of this means that plugin evaluation is fully under control of the
caller, but the caller has to know what the plugin names are a priori,
while module evaluation order is not at all in control of the caller,
but the caller can stop evaluation at any time.

The ability to call a specific plugin is clearly desirable.  The
ability to evaluate all modules of a given type (a la PAM) is also
desirable (but surely we don't want all the complexity of a PAM-like
evaluation control system).  So I think both systems are needed.
Besides, it seems both of these systems are in use in production, near
as I can tell (in the Apple tree both are used; in the Heimdal tree
the module system is not used), so removing one is hardly an option.

Given all of the above, I think that while the "eval all until one
succeeds or fails hard" approach of modules is very well suited for
aname2lname, the lack of control over evaluation *order* is
inappropriate for aname2lname.  The lack of registered module support
also means that any built-in simple DB (e.g., a binary search of a
flat text sorted file) has to be invoked explicitly by
krb5_aname_to_localname() (not a big deal).

Conclusion: either we must add a way to impose evaluation order on
modules (and, possibly, module registration), or we must use plugins,
not modules for aname2lname.

Comments?

Nico
--