If the master iprop log is reinitialized to serial number 0, slaves
will need to take a full dump--but after that happens, we need to know
whether the slave has taken that full dump, we we don't offering full
dumps indefinitely.

So, record a timestamp in kdb_last_time when we reinitialize the log
header, and compare the slave timestamp to kdb_last_time whenever it
has the current serial number, even if it's 0.  Test this by
performing a propagation with sno 0 in t_iprop.py and detecting
whether kpropd gets a second UPDATE_FULL_RESYNC_NEEDED response from
kadmind.

ticket: 7550 (new)

Use a global dump (the default dump file) for full syncs for iprop.
When a slave asks for a fullsync we kprop the existing global dump to it
if that is good enough, else we dump the DB and send the new global
dump.

Before this change kadmind would run kdb5_util dump -i... each time a
slave asked for a full dump.  This was done in a sub-process,
thankfully, but it was still a waste of time and storage (e.g., if one
has a huge KDB).

Also, long dump times might cause a slave to give up (the timeout for
this is now configurable).  But since iprop dumps bear a serial number
and timestamp and since slaves will resync from that point forward, it
doesn't matter if the dump we send a slave is fresh as long as it is
fresh enough (i.e., that its sno and timestamp are in the ulog).

Also:

 - Rename dumps into place instead of unlink, create, write (but we
   still keep the dump ok files as lock files and as a method of
   signaling to kprop that the dump is complete).

ticket: 7371

This simply adds KADM5_API_VERSION_4 and various fields to the
policy structures:

 - attributes         (policy-ish principal attributes)
 - max_life           (max ticket life)
 - max_renewable_life (max ticket renewable life)
 - allowed_keysalts   (allowed key/salt types)
 - TL data            (future policy extensions)

Of these only allowed_keysalts is currently implemented.

Some refactoring of TL data handling is also done.

ticket: 7223 (new)

r24314 (#6778) created a hybrid owernship model for the master key
list, with one virtual copy stored in the DAL handle and one provided
to the caller of krb5_db_fetch_mkey_list.  Replace this with a model
where only the DAL handle owns the list, and a caller can get access
to an alias pointer with a new function krb5_db_mkey_list_alias().
Functions which previously accepted the master key list as an input
parameter now expect to find it in the DAL handle.

Patch by Will Fiveash <will.fiveash@oracle.com>.

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@25781 dc483132-0cff-0310-8789-dd5450dbe970

Add a new API krb5_dbe_compute_salt() to determine the salt for a key
data entry, and use it in the three places we currently compute salts.

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@25410 dc483132-0cff-0310-8789-dd5450dbe970

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@25214 dc483132-0cff-0310-8789-dd5450dbe970

Create a new tl-data type to hold the time of the last administrative
unlock, and factor it into decisions about account lockout.  Since
tl-data values are propagated from master to slave, this will cause
modprinc -unlock operations to reach slave KDCs on the next
propagation.

ticket: 6795

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@24424 dc483132-0cff-0310-8789-dd5450dbe970

Previously, code needed to run a loop to find the current master key,
possibly fetch a new master key list and try finding the master key
again around each key decryption.  This was not universally done;
there are cases where only the current master key was used.  In
addition, the correct ideom for decrypting key data is too complicated
and is potentially unavailable to plugins that do not have access to
the master key.  Instead, store the master key list in the dal_handle
whenever it is fetched and permit a NULL master key for
krb5_dbe_decrypt_key_data.

* Remove APIs for krb5_db_{get|set}_mkey_list
* krb5_db_fetch_mkey_list: memoize master key list in dal_handle
* krb5_db_free_mkey_list: don't free the memoized list; arrange for it to be freed later
* krb5_dbe_decrypt_key_data: Search for correct master key on NULL argument
* change call sites to take advantage

ticket: 6778

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@24314 dc483132-0cff-0310-8789-dd5450dbe970

API, replacing the last method (CHECK_ALLOWED_TO_DELEGATE) of
db_invoke.  Remove db_invoke since it no longer has any methods.

ticket: 6749

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@24189 dc483132-0cff-0310-8789-dd5450dbe970

replacing the REFRESH_POLICY method of db_invoke.

ticket: 6749
status: open

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@24187 dc483132-0cff-0310-8789-dd5450dbe970