> The 'rand' file manipulated by the routines in crypto/rand/randfile.c is not > correctly handled on OpenVMS when multiple instances of the client are active > in the same working directory concurrently from multiple nodes in a cluster. > The relevent code is at line 217ff in v0.9.8i which reads: > > rename(file,";1"); /* Make sure it's version 1, or we > > Unfortunately, when this code is running concurrently as described above, VMS' > RMS sometimes returns an RMS$_REENT error from the rename, and the file > becomes > orphaned on the file system and must be manually recovered with an > Analyze/Disk/Repair operation.
Wouldn't it be more appropriate to simply ensure that version number doesn't increase and skip the rename altogether? As far as I understand it's possible by opening file in shared mode, by passing "shr=???" argument to [f]open... > I think the bigger > question I need to answer here is more of a _general_ issue with how openssl > expects to actually USE the randfile routines and contents. OpenVMS really > only > points out that there is a possible general issue here. > > The routine in question, RAND_write_file(), creates a new rand file, and then > immediately closes the file ... This is then subsequently reread, apparently, > using RAND_load_file(). This would seem to me that any callers of > RAND_load_file() might have an expectation of getting back the exact data that > they wrote into the rand file earlier, or at least, of getting *some* data > back. Keyword is "caller" and it's actually *you*, or more exactly application running on your behalf. Note distinction between implementation of RAND_[read|write]_file residing in library and application using it. Basically it's application's responsibility to live up to its own expectation. If you're referring to openssl binary built in the process, then it's admittedly might be and very likely is inappropriate to use it the way you describe. In which case you'd have to find or write another application better suited for your environment (e.g. not relying on default .rnd, but explicitly using node-specific names) or arrange appropriate setup (e.g. by changing current working directory to node-specific location). > IF these RAND library calls are running concurrently from multiple > processes attempting to write these files into the same directory, then it > would seem that there's going to be some unexpected or unpredictable results > from this. Unpredictability is not a problem here, predictability is. What's inappropriate is to reuse same .rnd content, e.g. when two processes read same .rnd and seed their generators with it. In other words if .rnd is significant entropy source, it would be basically inappropriate to start two copies of application at the same time, so that first process doesn't have opportunity to fulfill RAND_write_file prior another calls RAND_read_file. One can argue that library could do synchronization magic, but it would be very system and even environment specific, which is why the responsibility lies at application. One can argue that openssl binary could do better job, but it was always was kind of least common denominator application, which is meant to perform rare tasks (such as long term key-pair generation), to test things and to be a sample for other application programmers. To summarize. It seems appropriate to find alternative way to handle VMS file versioning (I can imagine that avoiding version increase is more efficient and most appropriate). Can you experiment with "shr=???" options? Yet you should reconsider your application usage pattern in your environment. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
