Password quality pluggable interface scope

[Greg Hudson]

On Fri, 2010-08-27 at 12:06 -0400, Marcus Watts wrote:
> I reworked the containing logic to apply even if there
> was no policy, and passed the policy *name* (or a null ptr if no policy)
> into the plugin in case the pw quality plugin wanted to do something
> different depending on the policy.

That's a decent compromise between keeping things simple and providing
some amount of policy configurability.

> I put a fair bit of effort into one other thing you don't list above:
> configuring the plugins, and providing 'system' parameters for the plugins.
[...]
> 	/2/ loading the same plugin more than once with different configuration.
> ... so I wasn't very interested in "zero configuration" rules.

Plugin modules can read profile associations; consider PKINIT
configuration variables, for example, or LDAP back-end configuration.
Is there a reason you prefer configuration of plugins to be modeled as
system parameters?  What are the use cases for loading the same plugin
more than once with different configuration?

> As I said before, I think the built-in parameters for policy records
> is unduly restrictive.  I'd like to see a much more extensible format here.

I would too, but I'm afraid this aspect will probably have to wait for a
more comprehensive KDB-related project.  We've had other requests for
KDC-related plugins to be able to store extensible data within the KDB,
so that may be a 1.10 project.