| Subject: | kadmind caches master key activation times |
The master key activation times list is a tl-data value on the K/M entry
containing {kvno, time} tuples, and determines which master key is
considered "active" for the purpose of encrypting new keys.
kadmind reads this list at startup by calling
krb5_dbe_fetch_act_key_list, and stores it in a global variable
active_mkey_list. This value is never updated during the lifetime of
the kadmind process. As a result, kdb5_util use_mkey operations will
not affect a running kadmind process. This appears to have been
considered in the project page, but is not documented in the kdb5_util
man page.
We can either document this or fix it. Fixing it means looking up the
K/M DB entry for every key change operation
(cprinc/chpass/chrand/setkey), which is probably not a big deal. We
already do that for the history key for chpass, which is the most common
key change operation, and if we ever implement #1221 we could collapse
those into one lookup (for new databases).
containing {kvno, time} tuples, and determines which master key is
considered "active" for the purpose of encrypting new keys.
kadmind reads this list at startup by calling
krb5_dbe_fetch_act_key_list, and stores it in a global variable
active_mkey_list. This value is never updated during the lifetime of
the kadmind process. As a result, kdb5_util use_mkey operations will
not affect a running kadmind process. This appears to have been
considered in the project page, but is not documented in the kdb5_util
man page.
We can either document this or fix it. Fixing it means looking up the
K/M DB entry for every key change operation
(cprinc/chpass/chrand/setkey), which is probably not a big deal. We
already do that for the history key for chpass, which is the most common
key change operation, and if we ever implement #1221 we could collapse
those into one lookup (for new databases).