Password sync plugin, and questions about plugin criticality

[Nicolas Williams]

On Mon, Jun 26, 2006 at 09:00:27PM +1000, Luke Howard wrote:
> Right, but I'm thinking about a generalized plugin interface that we
> could use for implementing things like arbitrary KDC extensions.

Hmmm, I'm not sure you can generalize them all.  A GSS-API mechglue, for
example, is not at all like SLAPI or PAM in that the mechglue has to
keep significant state and "route" calls to mechanisms.

Also, if an SPI has a large number of functions then the framework and
its plug-ins may initialize more quickly if a structure full of function
pointers is used to register most SPI entry points.  In OpenSolaris
libgss uses just this approach, and dlsym()s only new entry points.  So
to always dlsym() entry-point-by-entry-point or have SLAPI like
per-entry-point registration need not be appropriate (but do we care
about init performance?  is dlsym() slow?).

A pre-auth plug-in framework should be a pretty dumb thing.  As should
be a KDB plug-in (except that to present the KDB "API" that MIT
kdc/kadm5srv code expects may require some ugliness).

A password synch framework should just call all its plug-ins, in order
or concurrently, who cares -- synchronization failures should be logged,
but that's it.

PAM configuration evaluation is significantly more complicated.  Of
course -- I'd not offer that as an example to follow, but its dlsym() a
symbol-at-a-time approach is quite fine for small SPIs, and has nothing
to do with PAM's control directives.

Nico
--