[krbdev.mit.edu #5777] keytab iteration + search don't mix

[Ken Raeburn via RT]

The iteration interface in the kt_file code assumes that the file handle is kept open, and an 
advisory lock is kept on the file.  The get_entry interface opens and closes the file, with an 
advisory lock for the duration of the call.  If a get_next call is made after get_entry, it will 
attempt to use a bogus file handle.

It should be possible to use get_entry while an iterator is active (in the same thread or 
different threads), without losing the advisory lock.  It should also be possible to use two 
iterators at once.

To make things more fun, both of those interfaces open the file read-only; the add and 
remove calls open it for write access.  So, calling add or remove while an iterator is active 
means getting write access while we've already got a read-access handle on it.  And 
remember, under POSIX, closing any handle on the file means releasing any advisory locks we 
have on the file (not just via that handle).  So the obvious workaround of using multiple 
keytab objects referring to the same file will likely cause incorrect handling of the advisory 
locks because of this.

Possibly add/remove should be disallowed while an iterator is active, because of the 
conflicting locking requirements?  Or, the iterator could be invalidated.

On the other hand, do we need to maintain the read lock while between reading entries, or is 
it sufficient to use lock-read-unlock sequences?  (The add action works by appending; 
remove works by overwriting with a dummy value, all zeros aside from the length indicator.  
So I think mixing iterators and add/remove should be safe.)