Preliminary discussion: DB alias entries

Love Hörnquist Åstrand lha at
Wed Mar 4 20:47:47 EST 2009

Put alias key in namespace that normal key not is in, no collisions  
then with old codebase. make alias data an indirection to real entry

Skickat från min iPhone

4 mar 2009 kl. 16.56 skrev "ghudson at" <ghudson at>:

> I've been asked to at least try to implement alias entries in the
> shipped KDB back ends for the 1.7 release.
> The main use case I have in mind for this work is servers with more
> than one name (which we currently tend to handle on the client through
> DNS canonicalization, which is awful).  I am not looking into
> case-folding for this project, as we have very limited time and there
> are some design issues there.
> 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.
> I've looked into three basic options for adding alias entries to the
> DB2 back end:
> 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.
> 2. Define a magic type of principal entry marked by a len value of 0
>   or some other magic value.  Unfortunately, the existing <1.7
>   parsing code does not check the length field until it is done
>   decoding all of the integer fields of the entry (it does check the
>   length of the value blob, so there's no input buffer overrun), so
>   it wouldn't fail very gracefully on seeing an alias entry.
> 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.
> Option #3 seems the most practical.  krb5_db2_db_get_principal would
> check the result for the tl_data canonical name field, and would
> follow the link.
> Comments on this so far?  I'll be fleshing this all out into a
> detailed project proposal over the next couple of days.
> _______________________________________________
> krbdev mailing list             krbdev at

More information about the krbdev mailing list