Preliminary discussion: DB alias entries

[Luke Howard]

> I'm currently planning to add support to the LDAP back end as well as
> the DB2 back end for feature parity, but I don't yet understand that
> code well enough to understand the design alternatives.  This message
> will focus on the DB2 back end.

For the LDAP code, the simplest approach might be to add a canonical  
principal name attribute. Which reminds me, the following usage of  
strcaescmp() in krb5_ldap_get_principal() is somewhat dubious:

                 /* a wild-card in a principal name can return a list  
of kerberos principals.
                  * Make sure that the correct principal is returned.
                  * NOTE: a principalname k* in ldap server will  
return all the principals starting with a k
                  */
                 for (i=0; values[i] != NULL; ++i) {
                     if (strcasecmp(values[i], user) == 0) {
                         *nentries = 1;
                         break;
                     }
                 }

> 1. Store the same entry data with multiple keys:
>
>   principalname -> { info, principalname, tl_data, key_data }
>   aliasname -> { info, principalname, tl_data, key_data }
>
>   This is sort of elegant in that it doesn't modify the DB schema and
>   doesn't require any changes to the lookup path, but it introduces
>   consistency issues--if you change the password of the principal,
>   the aliases don't get updated.

Could you have absent key data (or a magic value indicating it was an  
alias).

> 3. Define a magic type of principal entry structured as a current
>   principal entry, but with most of the integer fields being 0, no
>   key data, and with a single piece of tl_data giving the canonical
>   name of the principal.

Well, there you go. :)

-- Luke