Pasword quality pluggable interface project review

[Greg Hudson]

On Sun, 2010-08-29 at 23:16 -0400, Marcus Watts wrote:
> Modern versions of k5 install kadm5/admin.h.  I don't see a problem with
> including it.  It would be odd that something that's going to be running
> inside kadmind's process space can't see/use the public api for kadmind.
> Being able to return the exact error code desired, IMHO, is the right
> thing to do.

That's fair.  For the moment I've taken that direction.

My concern was that kadm5/admin.h has explicitly lower stability
guarantees than other APIs, but KADM5_PASS_Q_* error codes don't have to
be part of that instability.

> 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.

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

> ____ 2. why load a plugin more than once?
> [...]

I touched on this elsewhere in the thread.

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.

> ____ 3. my modified version of rra's mechanism
> 
> This may not be of interest to you, but in case it's helpful

It's definitely a useful reference point, as Russ's code has been.

> The "exec" plugin is intended to provide the functionality of
> USE_PASSWORD_SERVER which invokes /usr/sbin/mkpassdb on password changes.
> "exec" is another example of a plugin one might choose to load more
> than once.

Under the plugin infrastructure we chose, if an exec plugin were
desirable, I imagine that it would read a list of programs to execute
from the profile.

> 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.)