Frank Cusack <fcusack@fcusack.com> wrote:
It's fairly obvious from the code.
OK. A work-around can be to do: static int initialized_flag = FALSE; instantiate() { if (!initialized_flag) { do stuff... } } I wouldn't worry about the "destroy" function.
I open a single file handle to /dev/random, shared by all instances, and I setup an hmac key which I need to sign access-challenge STATE attributes. I close the fd and clear the hmac in destroy.
A *larger* issue is that you shouldn't be using /dev/random, as it's blocking. It's also non-portable (for what that's worth). I suggest using lrad_rand(), which returns a cryptographically strong random 32-bit integer. As for signing the State attribute, the HMAC key can also be generated by using lrad_rand().
You're right, no module *needs* init and destroy. These are easily simulated with pthread_once() and a refcount, but you can consider the modules to be classes, and a static constructor and destructor is a natural for them. init and destroy methods make sense.
And LD_PRELOAD as class overloading... (yes, I've done it)
There's no reason a module *has* to use them, but they should be there if you want them.
We can add them back in, but I don't think they're *required* for what you're doing. The hmac key for signing State SHOULD be per-instance, too. Otherwise you run into the issue of one OTP module getting a State from another one, and not knowing what to do with it. Alan DeKok.