[krbdev.mit.edu #7522] krb5-1.11, patch 1 of 4

[Greg Hudson via RT]

Resetting the ulog header to the zero state is not an adequate way to 
force a full dump as things currently stand, for several reasons:

1. Let's say a slave's serial number is N, and then a policy operation 
happens on the master.  If N additional principal operations occur on 
the master before the slave asks for incrementals, the slave and master 
will have the same serial number and the slave will appear up to date.  
(Variations on this problem occur if slightly more than N updates occur 
on the master before the slave asks.)

2. Conversely, if the slave takes an update immediately (while the 
master's sno is still 0), the slave will transmit an sno if 0 when it 
next asks for incrementals.  The master will interpret this as a slave 
with a fresh database, and will say a full dump is needed again.  So a 
slave could continually take full dumps over and over again after a 
single policy change.

3. Assume we fix #2 somehow.  Now, say a policy change happens, then a 
slave takes a full dump, then another policy change happens.  How do we 
know that the slave should take another full dump?

It turns out that the iprop protocol and on-disk metadata include 
timestamps as well as serial numbers.  These can be used to detect 
reused serial numbers and address the above problems.  But (1) we would 
need to fix iprop_get_updates_1_svc and ulog_get_entries to actually use 
the timestamps instead of just ignoring them, and (2) when we 
reinitialize the ulog, we need to set the timestamps to the current 
time.  There are also potential issues with multiple changes occurring 
within the granularity of gettimeofday(), although those may be minor.  
More fully implementing timestamps also has the benefit of handling some 
wrapped-sno scenarios.

Alternatively, we could force a full dump by just setting kdb_first_sno 
equal to kdb_last_sno + 1.  I'm not sure if there would be problems with 
the details there (like what do we set kdb_first_time to?).

(Side note: kproplog -R has the same problem as this proposed patch.)