Preliminary discussion: DB alias entries

[Love Hörnquist Åstrand]

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 mit.edu" <ghudson at mit.edu>:

> 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 mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev