On August 23, 2005 6:55:09 PM -0400 Alan DeKok <aland@ox.org> wrote:
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... } }
Sure, but that's awkward compared to having an init method. As an aside, I thought instantiate ran on each thread creation, but I see now it's a config-based thing and runs in a single thread (so I don't need pthread_once()).
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.
I misspoke; I actually use /dev/urandom.
It's also non-portable (for what that's worth).
It's as portable as I require. Systems that don't have it really aren't worth running on. :-)
I suggest using lrad_rand(), which returns a cryptographically strong random 32-bit integer.
I also need it to generate challenges, which is also found in my other otp code (non-freeradius), and much code is shared with rlm_otp. It doesn't really help me to use lrad_rand().
We can add them back in, but I don't think they're *required* for what you're doing.
They're not; I don't think I ever disputed that. I just don't see the point of removing them, and making instantiate() awkward for the few modules (now and perhaps later) that need them.
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.
I don't see how that can happen. If one instance of the OTP module generates State, that same instance will be the one to process it. It works at my site, at least. -frank