David Woodhouse <[email protected]> writes: > When using HOTP tokens (and OCRA with a counter), we really want to > atomically: > > - Load the contents of a PSKC file. > - Generate a keycode and increment the counter in the pskc_key_t > - Save the new counter value back to the file. > > That way, multiple applications can be using keycodes without corrupting > the file or re-using the same code. > > So we need to have a defined method of *locking* the file — either with > a separate lockfile, fcntl locking, or something. > > Does anyone have any opinions on *what* that method should be?
First let's take a step. Why do you want to increment the counter and save it back to the same file, in a concurrent-safe way? Are you using the PSKC file as the "live" database format in some application? PSKC was meant for transportation and provisioning, and thus meant to be imported to either a device or a server. In my mind, servers would use a rather different storage format for token data when it is actually running and validating OTPs. The server could support import/export of the then-current data, in PSKC format, if it wants too, but it wouldn't require concurrent-safe operations. I'm not saying what you are doing is a bad idea and oath-toolkit shouldn't support it, I'm just trying to understand what you are doing. Adding more server functionality, or at least more APIs to support server implementations, to oath-toolkit generally seems like a good idea to me. /Simon
