[please pardon me if this is a duplicate -- the first attempt seemed to
disappear]
I have run into a problem on OpenVMS with the .RND file that openssl
creates ... in researching this though, it looks like there could be
some unexpected behavior on other platforms as well ... I would appreciate
any sage insight that some of you may be able to share.... Thanks!
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. VMS' message help $ HELP/MESS REENT/FAC=RMS has
this to say about the error:
REENT, file could not be renamed and recovery failed; file has been
lost
Facility: RMS, OpenVMS Record Management Services
Explanation: An RMS $RENAME operation failed and the attempt to recover the
file's directory entry also failed. The file has become a lost
file.
User Action: Either use the Analyze/Disk/Repair utility to recover the lost
file, or ask your system manager to recover the file.
That little bit there about using Analyze/Disk/Repair also has a nasty little
side effect. I discovered this problem when a user of one of my application
programs complained that 130,000 copies of ".RND;nnn" had been lost to the
filesystem, AND... that due to VMS' 32767 file version maximum, ONLY 32767
of these could be recovered per Analyze/Disk/Repair run. Deleting 32767
versions is also not fast. Needless to say, that wasn't a fun day for my
application user.....
This is actually an error inside the VMS RMS $RENAME system service, but I
think the likelihood of getting it fixed by HP is fairly low. I plan to ask
anyway. Therefore, I have written code that I am willing to contribute which
can capture and recover from this situation without corrupting the filesystem,
but when it happens, I'm left holding the file_id (inode number) of the
orphaned file, and not too good of an idea what exactly I should DO with it --
i.e. what should I call it? -- can I just delete it?? 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. 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. This seems like it would happen at least on unix and windows
as well as OpenVMS.
Any insights would be most appreciated...
Thanks.
David
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
