Difference between revisions of "Projects/Replay cache improvements"
From K5Wiki
< Projects
| Line 1: | Line 1: | ||
{{project-early}} |
{{project-early}} |
||
| + | |||
| + | ==Background== |
||
http://colabti.org/irclogger/irclogger_log/krbdev?date=2014-08-26 |
http://colabti.org/irclogger/irclogger_log/krbdev?date=2014-08-26 |
||
| ⚫ | |||
| + | ==Correctness== |
||
| + | |||
| + | The current implementation has the following possible issues with correctness: |
||
| + | |||
| ⚫ | |||
| + | |||
| ⚫ | |||
| + | |||
| + | * 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. |
||
| + | |||
| + | ==Performance== |
||
| + | |||
| ⚫ | |||
| + | |||
| + | ==Short-term solutions== |
||
| + | |||
| + | * 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 |
||
| + | |||
| + | ==Medium-term solutions== |
||
| + | |||
| + | * New file-based replay cache, possibly hash table based |
||
| + | |||
| + | * IPC-based replay cache for higher performance |
||
| ⚫ | |||
| + | ==Long-term solutions== |
||
| ⚫ | |||
| + | * Revise protocols to not require replay caches for security |
||
Revision as of 18:00, 26 August 2014
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.
Contents
Background
http://colabti.org/irclogger/irclogger_log/krbdev?date=2014-08-26
Correctness
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.
Performance
- Use of fsync() can cause performance problems. [krbdev.mit.edu #372]
Short-term solutions
- 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
Medium-term solutions
- New file-based replay cache, possibly hash table based
- IPC-based replay cache for higher performance
Long-term solutions
- Revise protocols to not require replay caches for security
