[1919] in Kerberos_V5_Development
Re: Cygnus changes for your consideration
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Thu Oct 31 14:33:30 1996
Date: Thu, 31 Oct 1996 14:29:09 -0500
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: eichin@cygnus.com
Cc: tytso@MIT.EDU, krbdev@MIT.EDU
In-Reply-To: <xe1u3rbknh4.fsf@maneki-neko.cygnus.com> (message from Mark
Eichin on 31 Oct 1996 13:17:11 -0500)
> Ah... so this only affects handling the kdb layer, right? In that
> case, it should not conflict with the policy database changes I made.
Correct, it doesn't touch anything policy related. The changes are in
kdb_dbm.c and dbutil/dump, nowhere else.
I made some changes to the way dbutil/dump.c handles the policy db.
But, if you only changed kdb_dbm.c and code that calls it, I don't
think there will be conflicts.
> principal's tl_data with what was given as input, with the exception
Ok; does the client already fetch the tl_data then, or will I have to
add that with my changes to actually generate some?
kadmin_modprinc() in kadmin.c does not currently retrieve the tl_data,
but it does already call kadm5_get_principal, so you just need to add
" | KADM5_TL_DATA" to the mask and then copy it to the princ that will
be passed to kadm5_modify_principal. I'd suggest
princ.tl_data = oldprinc.tl_data;
oldprinc.tl_data = NULL;
so kadm5_free_principal_ent(handle, &oldprinc) won't actually free the
tl_data you want to keep (otherwise you'd have to duplicate it).
And how does this
interact with tl_data types that the server knows about (mod time and
such that are stored in tl_data)?
The client has to pass to kadm5_modify_principal all the tl_data
entries that it got from kadm5_get_principal that it does not
explicitly know about.
(I think it's ok, but those
examples should make it clear that you can *never* correctly set the
tl_data from scratch, you can only ever fetch-modify-replace...)
Which examples? In any case, yes, the kadm5 functional spec should
say this.
Barry
