Password quality pluggable interface scope

Russ Allbery rra at stanford.edu
Fri Aug 27 14:35:42 EDT 2010


Greg Hudson <ghudson at mit.edu> writes:

> I hadn't run across krb5_appdefault* before; I don't think it would be
> appropriate for plugins, but I am curious what's horrible about it.

All the krb5_appdefault* functions return void.  Including the ones that
need to allocate memory to get the value, so memory allocation failure is
indistinguishable from the value not being set.

There are is no corresponding free function for the ret_value in
krb5_appdefault_string, so you cannot use the function safely on Windows.

There's no way to set a NULL default for krb5_appdefault_string since it
unconditionally calls strdup on the default and segfaults if you pass in
NULL.  You have to pass in the empty string and then special-case that as
a result, with a pointless strdup of the empty string in the Kerberos
library.

The functions take the realm as a krb5_data struct, which is about the
most inconvenient way possible to take the realm since application code
normally has the realm as a string.

krb5_appdefault_boolean sets an int * instead of a krb5_boolean * (it uses
krb5_boolean in Heimdal).  So far, this hasn't mattered, thankfully.

There's no krb5_appdefault_number, so you have to roll your own using
krb5_appdefault_string and then hope that it doesn't run out of memory
while it allocates the temporary string that you're then going to free.

There's no way to retrieve all the settings of a parameter that's repeated
in krb5.conf (something similar to the kdc parameter in [realms], for
example).

If you take 30 possible parameters (which is low for a good Kerberos PAM
module), you have to call krb5_appdefault* 30 times to determine that none
of those parameters are set.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the krbdev mailing list