issue with database_name parameter

[Will Fiveash]

On Fri, May 12, 2006 at 01:01:15PM -0600, Shawn Emery wrote:
> 
> Will Fiveash wrote On 05/11/06 14:54,:
> >On Thu, May 11, 2006 at 04:38:52PM -0400, Ken Raeburn wrote:
> >
> >>On May 11, 2006, at 15:46, Will Fiveash wrote:
> >>
> >>>I've noticed that the latest MIT krb code with LDAP support appears to
> >>>ignore the database_name if it is located in a [realms] section  
> >>>entry in
> >>>the kdc.conf (kadmin.local issues an error stating the KDB does not
> >>>exist).  If I place the database_name in a [dbmodules] section  
> >>>entry in
> >>>the krb5.conf then kadmin.local works.
> >>
> >>Yep, this was an unfortunate effect of the DAL integration.  To fix  
> >>it, I'm working on changes so that the KDC will consult both kdc.conf  
> >>and krb5.conf, combined, for its configuration information.
> >
> >
> >Okay.  BTW, found another bug:
> >
> >In krb5_rc_resolve_full() there is:
> >
> >    if ((retval = krb5_rc_resolve_type(context, id,type))) {
> >        FREE(type);
> >        k5_mutex_destroy(&(*id)->lock);
> >        FREE(*id);
> >        return retval;
> >    }
> >
> >however in krb5_rc_resolve_type() there is this:
> >
> >    for (t = typehead;t && strcmp(t->ops->type,type);t = t->next)
> >    ;
> >    if (!t) {
> >        k5_mutex_unlock(&rc_typelist_lock);
> >        return KRB5_RC_TYPE_NOTFOUND;
> >    }
> >
> >If return KRB5_RC_TYPE_NOTFOUND; is executed the krb5kdc will core dump on:
> >
> >        k5_mutex_destroy(&(*id)->lock);
> >
> >Note this occurred when I did:
> >
> >krb5kdc -n -R FILE:/usr/local/krb_ldap/var/krb5kdc/rcache
> 
> This is a known issue that I filed back on 1/9/06:
> #3332 rcache mutex access

Cool, thanks for the info.

-- 
Will Fiveash
Sun Microsystems