Extensible kadm5 policies

[Nico Williams]

On Tue, Nov 1, 2011 at 11:58 AM, Greg Hudson <ghudson at mit.edu> wrote:
> On 11/01/2011 11:11 AM, Nico Williams wrote:
>> But I do have a good reason for this, courtesy of Jeff: not all
>> Kerberos realms will be enforcing a corporate policy, but rather a
>> user policy.  Consider a commercial Kerberos realm, or a commercial
>> service that uses Kerberos for authentication, including having a
>> realm for its users (or some of them).  Why wouldn't the service
>> operator want to allow users to be more paranoid than the service
>> operator is?  Why wouldn't the service operator at least want this
>> option?
>
> If I were designing from scratch, and I wanted to accommodate this, I'd
> design for it by saying that each principal has an associated policy
> which is initially empty (or null/created on demand).  Then the admin UI

As long as that policy does not have to be deleted separately (and
preferably also not created separately), sure, but then it'd be hardly
distinguishable from saying that policy fields are also fields of
principals.  Otherwise you could argue that we already have this, and
that the only issue is that you have to remember to delete/rename
policies when you delete/rename users -- that'd be lame.

> would have a way of referring to a principal policy as well as a named
> group policy.  That way all of the policy fields are semantically
> contained within the appropriate object, but the group policy namespace
> doesn't get proliferation.

I'll consider this.

> Alternatively, I might decide that this use case isn't very
> compelling--that is, if you're running a very heterogeneous realm,
> policy proliferation is a reasonable price to pay for that.

The main issue with this is garbage collection and authorization to
create and modify policies.  Plus we'd need at least two policies
per-principal: the one the user is allowed to modify and the one the
user is not allowed to exceed (much less modify).

> Of course, we aren't designing from scratch, and we already have policy
> fields in principals, so the above is mostly a mental exercise in where
> we might want to end up down the road if we think we can get there.

Right: the context is the implementation that we have now.  With that
context in mind the path of least resistance is more or less as I
described -- and it's not just a hack for being the path of least
resistance, as much legacy code would get thrown out in the process.

> When we added principal string attributes for 1.10, we decided to
> abandon the unitary get_principal/set_principal architecture and just
> define new RPCs to get and set string attributes.

I'm not sure I like this.  But without a way to do atomic transactions
this is better than the original protocol.  (This is where LDAP is
better, of course -- it's a standard protocol with enough atomiticy
for our purposes.  Sadly, if one does not want LDAP for the KDB... but
no one is going build an LDAP front-end (or plugin to OpenLDAP, say)
to access a db2 KDB.)

> It might be reasonable to (a) decide on what general policy extension
> framework we want (tl-data, string attributes, both, something else),
> and (b) define new RPCs to set and get policy extensions.  We wouldn't
> need to completely migrate away from the blobby architecture at this time.

If I offer to get away from what Tom called "blobby" it's partly to
address complaints about accumulation of legacy code, and partly
because I myself would prefer an accessor interface.

> As for making this the last time we break the kadm5 API/ABI, we very
> explicitly have not committed to keeping it stable and do not want to
> make that commitment in its current form.  We didn't install
> kadm5/admin.h at all until 1.7, and we started doing so with the
> documented understanding that it wouldn't be considered a stable API.
> If we see a lot of pressure to treat it as stable, we'll treat that as a
> lesson that we should never have installed it until we were more
> comfortable with it.

I would say that users know better than to bother asking you for a
stable admin API :)  We've just dealt with the instability here (and
in my old days as a sysadmin).  I'm giving you evidence that people
need stable admin APIs.  (See also Russ' rem_ctl.)  LDAP would have
been nicer if we'd been using it forever and if we'd had a great
schema from the word go.

>> Supposing that I couldn't think of a good reason for it, there's still
>> the fact that someone else might,
>
> This is getting a little far afield, but philosophically I'm opposed to
> this kind of reasoning.  A lot of Kerberos's complexity comes from
> designing facilities nobody had a present need for.  Design for
> extensibility, yes, but not for unneeded generality.

I agree -- it was lazy of me to make that argument.

Nico
--