Pasword quality pluggable interface project review

[Nicolas Williams]

On Mon, Aug 30, 2010 at 12:57:18PM -0400, Greg Hudson wrote:
> On Sun, 2010-08-29 at 23:16 -0400, Marcus Watts wrote:
> > I agree the existing error codes are pretty narrowly scoped.  I'm not
> > sure how I'd add more to be useful, given the error codes should be
> > remotely visible.
> 
> It's apparent to me now that there's a lot of room for improving our
> support for password quality errors over the password change protocol.
> For schedule reasons, I'm going to defer that to future work--in
> particular, to the part of the future after we have localization.

Sure, the localization part is the tough one, so the most obvious to
defer.  But it's tough for the _plugin_, not the framework.

The plugin API should be able to cover localization.  All you need is: a
lnaguage tags input argument, and a {language tag, error message} output
parameter.

And note that it's OK for plugins to fail to localize but still output
an error string.

> http://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-set-passwd-08 says
> that for non-predefined password quality errors, the client may pass a
> set of languages to the server and the server must return a localized

To be fair, there aren't any implementations of that protocol.  But as
long as people may want to impose odd-ball password quality policies
we'll need effectively the same solution.

> error message.  As Nico noted, localizing an error message in a
> client-provided set of locales is not easy with current localization
> APIs.

It'd be possible to write one's own localization interfaces for this
very specific purpose.  And it's the plugin's problem.  The framework
itself should do no localization.

> > ____ 2. why load a plugin more than once?
> > [...]
> 
> I touched on this elsewhere in the thread.

BTW, note that dlopen() will only load a given module once (it uses
st_dev and st_ino to compare objects).  Calling dlopen() more than once
to open the same object (even through symlink aliases) results in a
handle for the same already-loaded object.

> It's true that PAM-like parameterization/multiple-registration allows
> the admin to build interesting stuff out of simple plugin modules.  One
> of my concerns is that this effectively creates a kind of "PAM
> programming" which isn't especially admin-friendly; a lot of admins
> would be better served by slightly more complex plugin modules and a
> less complex infrastructure.

Module parametrization is not the problem with PAM.  The problem with
PAM is the complex yet limited control facility.

For password quality policies you could (should!) call modules in order
and stop as soon as one returns an error.

Module parameters are avoided by the ability to call the profile API
from the module.  But you can then only have one instance of each
module.  I'm not sure that's really a problem.

> > This talks about "password synchronizing" - and I think this was
> > a requirement at one time of somebody (not me!) - but neither Russ
> > nor I think this is the right place to do this today.
> > That means neither of us really like USE_PASSWORD_SERVER.
> 
> We're planning to create a separate password synchronization interface
> modeled after the one in krb5-sync.
> 
> Although naively, password quality and password sync feel like the same
> kind of hook, once you get to the detail level they are rather
> different.  (Also, the easiest way of ensuring that password quality
> checks happen before password sync checks is to make them separate
> interfaces.)

They're quite similar.  At first glance I can only think of two
differences:

 - quality check failure -> fail the entire password change operation

   For password synchronization failures are more complex.  Failure to
   synchronize the first external system could fail the entire
   operation, but failure to synchronize subsequent external systems
   either must be ignored, or there must be a password change rollback
   method for the systems synchronized earlier.

   I think it's fair to assume that password changes cannot be rolled
   back.  Though maybe we could allow modules to have an optional
   rollback feature; all modules that support it can then be called
   first.

 - quality check requires more inputs:

    - the KDB entry, specifically, so the password quality module can
      check the user's password history (and maybe other things, such as
      user's languages, so that dictionary checks can be done for all
      the languages the user speaks)

Note though that both types of plugins need an optional language tags
input so they can localize error messages for the client user.

Nico
--