key handling in krb5_ldap_put_principal() issue

[Will Fiveash]

In fact as I debug my code changes there are a number of places where
the entries->mask is tested to determine what princ. attributes are
setup for storage.  If I change these like so:

    /* if (entries->mask & KDB_MAX_LIFE) { */
    if (entries->max_life > 0) {
        if ((st=krb5_add_int_mem_ldap_mod(&mods, "krbmaxticketlife", LDAP_MOD_REPLACE, entries->max_life)) != 0)
        goto cleanup;
    }

then I can get "kdb5_util create" to work properly with the ldap plugin.
Note that kdb5_util create calls krb5_db_put_principal() to create the
"magic" principals like K/M@<realm> and so on.  These principals were
not being created properly because the entries->mask is not being set
prior to krb5_db_put_principal() nor should it be set since this is
specific to the ldap plugin.  Thoughts?

On Thu, Sep 21, 2006 at 03:20:51PM -0500, Will Fiveash wrote:
> I have a question about this logic in krb5_ldap_put_principal():
> 
>     if (entries->mask & KDB_KEY_DATA || entries->mask & KDB_KVNO) {
>         int kcount=0, zero=0, salttype=0, totalkeys=0;
>         char *currpos=NULL, *krbsecretkey=NULL;
> 
> etc...  This code block sets up the tl_data for the keys associated with
> a princ record.  What bothers me is the only place I see: 
> 
> mask |= KDB_KEY_DATA;
> 
> is in kdb_ldap_create_principal() (I don't see where mask is set with
> KDB_KVNO).  Why doesn't the key logic in krb5_ldap_put_principal() look
> at entries->n_key_data and entries->key_data to determine if key data
> needs to be stored in the LDAP directory?

-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)