Extensible kadm5 policies

[Nico Williams]

On Mon, Oct 31, 2011 at 11:27 AM, Tom Yu <tlyu at mit.edu> wrote:
>>> As for ugliness, yes, it's ugly, but the current policy DB mess is far
>>> uglier,
>>
>> Doesn't justify adding more ugliness IMO.
>
> Let's make things prettier, not uglier.

Beauty is in the eye of the beholder, and besides, there's different
aspects of the proposed solutions, some of which aspects are ugly and
not.  The type overloading in the kadm5 API based on the version
identifier supplied by the caller is certainly ugly.  And as long as
we have any policy-type fields as fields of principals (e.g., ticket
max-life/max-renew-life) I think that treating policies and principals
as "derived from a common base class" is elegant.  What's decidedly
ugly about my proposal is the overloading of the principal entry
namespace, but we could just extend the DAL to provide an interface to
avoid this (though the db2 backend might still resort to namespace
overloading as a way to fit policies into the existing DB, which would
then be an implementation detail of the backend).

Also, arguably even my proposal as originally made would result in
cleaner code by removing the osa db and adding policy iprop support
without having to modify the existing iprop protocol.

But let's not get bogged down on what's beautiful and what is not.
I'd like instead to ask a few questions and see where the answers lead
us:

 - Do we want any policy fields to also be fields of principals?  Why/why not?

 - Do we want extensible policies at all?

 - Do we want to add a new kadm5 API version and overload the C types
one more time?  Do note the need to do the same in the protocol, or to
add new RPCs.

I must say that I'm not too upset by the idea of adding a new kadm5
API version and doign more type overloading *in MIT krb5*.  It would
never happen in Heimdal, but we can break kadm5 ABI there, so that's
not a big deal.  But for the db2 backend I'd still propose
policies-as-principals just so we can get policy iprop.

FYI, I can't get on freenode.  Something changed and it seems to
insist on SASL, which my IRC client can't manage.

Nico
--