oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

Fixes for updates of KADM5_KVNO but not KEY_DATA and vice-versa.

Browse Source 
It turns out that updates of kvno but not key data and vice-versa are
both, allowed and actually done (e.g, in kadmin's ank).  Doing the right
thing in these cases turns out to be a bit tricky, but this commit ought
to do it.
This commit is contained in:
Nicolas Williams
2011-07-21 17:39:53 -05:00
parent dae01950a2
commit e23a1efdc9
7 changed files with 125 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
lib/kadm5/ent_setup.c
View File

@@ -178,8 +178,27 @@ _kadm5_setup_entry(kadm5_server_context *context,
}
}
if(mask & KADM5_KVNO
&& princ_mask & KADM5_KVNO)
ent->entry.kvno = princ->kvno;
&& princ_mask & KADM5_KVNO) {
/*
* For some reason kadmin's ank changes the kvno after calling
* randkey. Now that we have key history, what are we to do
* when we update kvno but not keys?!
*
* For now just clear the key history if the kvno changes.
* Eventually we may want to search the key history for matching
* keys and use those to replace the current key set (putting
* the old current keyset in the history keysets list?!).
*/
if (ent->entry.kvno != princ->kvno &&
(mask & princ_mask & KADM5_KEY_DATA)) {
hdb_clear_extension(context->context, &ent->entry,
choice_HDB_extension_data_hist_keys);
princ->kvno = ent->entry.kvno;
} else {
/* _kadm5_set_keys2() expects this to have been done here */
ent->entry.kvno = princ->kvno;
}
}
if(mask & KADM5_MAX_RLIFE) {
if(princ_mask & KADM5_MAX_RLIFE) {
if(princ->max_renewable_life)