Fwd: Re: key handling in krb5_ldap_put_principal() issue

[Will Fiveash]

On Fri, Sep 22, 2006 at 04:24:01PM +0530, Praveenkumar Sahukar wrote:
> Hi Will,
> 
> >>>> On Fri, Sep 22, 2006 at  3:19 AM, in message <20060921214931.GB21466 at sun.com>,
> > Will Fiveash <William.Fiveash at sun.com> wrote: 
> >> 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?
> 
> For the "kdb5_util create" to work properly, the appropriate masks needs
> to be set. See below for more details.
> 
> >>
> >> 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?
> > 
> 
> Logic of checking the mask is same as what is used in the kadmin. In
> kadmin for every option mentioned (modprinc -maxlife ...), the
> appropriate mask is set. The same mask-set is used in the ldap plugin to
> create/update the attributes accordingly.
> 
> However, depending on values (entries->maxlife, ...) would mean acting
> on all the attributes that are present on the principal even when their
> mask is not set in the current request, as the complete information is
> passed on to the put principal. Additionally, depending on a value of 0
> for identifying if the attribute is set might not hold good in all cases.
> 
> Ldap plugins use a different set of macros (KDB_KEY_DATA, ...) that
> point to the same value as the KADM5_... macro counterpart. We are
> planning to use the KADM5 macros instead in the ldap plugins.

I see now that the problem is in the kdb5_util add_principal() function
that creates the magic princs.  It was not setting the mask and my
initial thoughts were incorrect.  I modified it to do:

entry.mask = (KADM5_KEY_DATA | KADM5_PRINCIPAL | KADM5_ATTRIBUTES |
    KADM5_MAX_LIFE | KADM5_MAX_RLIFE | KADM5_TL_DATA |
    KADM5_PRINC_EXPIRE_TIME);

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