| Subject: | keytab iteration + search don't mix |
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.)
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.)