Projects/Replay cache improvements
This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.
The current implementation has the following possible issues with correctness:
- Existing race condition when creating (or replacing on corruption). [krbdev.mit.edu #3498]
- Possible file corruption due to lack of locking and not using O_APPEND [krbdev.mit.edu #1671]. Probable mechanism is two processes nearly simultaneously writing at the same file offset, which will cause overlapping writes unless O_APPEND is set.
- Once a replay cache handle is open, entries written by other processes will not be detected.
- If another process does an expunge, the current process will not notice, and will continue to write entries to an unlinked file.
- Use of fsync() can cause performance problems. [krbdev.mit.edu #372]
- Fix the file creation race somehow
- Start using O_APPEND and detect when other processes have written entries
- Detect expunges by other processes
- Start using file locking
- New file-based replay cache, possibly hash table based
- IPC-based replay cache for higher performance
- Revise protocols to not require replay caches for security