logo_kerberos.gif

Projects/Replay cache improvements

From K5Wiki
< Projects(Difference between revisions)
Jump to: navigation, search
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
   
Existing race condition when creating (or replacing on corruption). {{bug|3498}}
+
==Correctness==
  +
  +
The current implementation has the following possible issues with correctness:
  +
  +
* Existing race condition when creating (or replacing on corruption). {{bug|3498}}
  +
  +
* Possible file corruption due to lack of locking and not using O_APPEND {{bug|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. {{bug|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
   
Possible file corruption due to lack of locking and not using O_APPEND {{bug|1671}}. Probable mechanism is two processes nearly simultaneously writing at the same file offset, which will cause overlapping writes unless O_APPEND is set.
+
==Long-term solutions==
   
Use of fsync() can cause performance problems. {{bug|372}}
+
* Revise protocols to not require replay caches for security

Revision as of 19: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
Personal tools