Pasword quality pluggable interface project review

[ghudson@MIT.EDU]

I uncovered one subtle issue during implementation: if a module's
check method decides it doesn't like a new password, what error code
should it return?

There are three error codes in kadm_err.et: KADM5_PASS_Q_TOOSHORT,
KADM5_PASS_Q_CLASS, and KADM5_PASS_Q_DICT.  Those error codes are
treated specially by kadmind's process_chpw_request().  But if plugins
are not tracking <kadm5/admin.h>, they won't have access to those
error codes.

krb5-strength sidesteps this issue by tying into find_word(), so that
all module errors are converted to KADM5_PASS_Q_DICT in libkadm5srv.

I can think of a few options which don't reintroduce <kadm5/admin.h>
into the API:

  * Add a boolean result argument to the check method, so that a
    failing password is not an error from the perspective of the
    pluggable interface.

  * Add a string result argument to the check method (to be set to
    NULL if the password passes quality checks), in the hopes that a
    module-generated explanation could be conveyed to the user.  No
    idea how this would ever be localized, though.  Also, the password
    change protocol doesn't appear to have a way to communicate such
    errors (looking at our implementation, anyway), so such strings
    would only show up in the kadmind log.

  * Create a new error in the krb5 table (or actually, the k5e1
    expansion table) for unspecified password quality failures, and
    treat that error code specially in process_chpw_request().