How to extend kadmin

[Greg Hudson]

On Thu, 2009-10-29 at 16:41 -0400, Greg Hudson wrote:
> 2. If we add an api_version field to the principal_ent and policy_ent
> structures, and custom encoding functions for those structures, then we
> can make those structure encodings dependent on the api_version while
> still using stock rpcgen for everything else.

I tried this approach and it doesn't quite work, unfortunately.  Without
marshalling the api_version of policy_ent_rec across the wire (which
would be wire-incompatible with krb5 1.7), we would still need custom
encoding functions for xdr_cpol_arg and friends in order to fill in the
api_version of the policy_ent_rec before decoding it.

Also, I uncovered another apparent obstacle to using stock rpcgen
encoders: many of our result encoders, like xdr_gpols_ret and
xdr_chrand_ret, conditionalize the encoding of result data on whether
the result code was success or not.

So, to summarize where we are:

* Lockout support on the trunk was done by revving the api_version field
from 2 to 3 and making the encoding of a policy_ent_rec conditional on
the api version.  (This is similar to how principal_ent_rec was extended
between api_version 1 and 2, but since we shed support for api_version 1
a while back, we aren't constrained by that.)

* If this code ships in 1.8, we will be committed to using custom
encoders for xdr_kadm5_policy_ent_rec, xdr_cpol_arg, xdr_mpol_arg, and
xdr_gpol_ret essentially forever.  This commitment likely already exists
for xdr_gpol_ret because of result-code conditionalization.

* Personally, I see a lot of obstacles to using rpcgen-generated
encoding functions for much of kadm5, and I don't see a lot of harm in
the current regime where we hand-edit code that was once created by
rpcgen in ages past.  So I don't plan to devote any more time "on the
margin" to forwarding this goal.  It may still be possible to use
rpcgen-generated client/or and server stubs; the lockout support doesn't
make that any easier or harder.