> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, August 29, 2012 1:44 PM > To: Tomcat Users List > Subject: Re: Windows Path Not Found for urandom > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jeffrey, > > On 8/29/12 1:57 PM, Jeffrey Janner wrote: > > Aug 29, 2012 11:52:29 AM org.apache.catalina.session.ManagerBase > > setRandomFile WARNING: Error reading /dev/urandom > java.io.EOFException > > at > > java.io.DataInputStream.readFully(DataInputStream.java:180) at > > java.io.DataInputStream.readLong(DataInputStream.java:399) at > > > org.apache.catalina.session.ManagerBase.setRandomFile(ManagerBase.java > > :548) > > > > > at > org.apache.catalina.session.ManagerBase.getRandomBytes(ManagerBase.java > :993) > > at > > org.apache.catalina.session.ManagerBase.init(ManagerBase.java:767) > > at > > > org.apache.catalina.session.StandardManager.start(StandardManager.java > > :630) > > ManagerBase > > > uses whatever it has been configured to use for the "random file" and > defaults to "/dev/urandom". > > The code in question should not execute unless /dev/urandom actually > exists -- see line 546 here: > http://svn.apache.org/viewvc/tomcat/tc6.0.x/tags/TOMCAT_6_0_33/java/org > /apache/catalina/session/ManagerBase.java?view=markup > > So, does /dev/urandom exist? Or, rather, does a file-exists check for > that path return true? Try this: > > System.out.println(new File("/dev/urandom").exists()); > > ...and see what happens. > > There is a setRandomFile(String s) method on ManagerBase, but it is not > documented anywhere in the Tomcat 6 documentation (nor can it be found > in the Tomcat 7 documentation). > > You could try to set the "randomFile" attribute on your <Manager> > element to point to some other file-based source of randomness, but I > doubt it will work. On Microsoft Windows, I think you want to have that > set to a path that does not exist so that java.security.SecureRandom > (by default) gets used for randomness. > > - -chris
Chris - Looking at that code, it looks like the only way to set the file is to change it there and recompile. The <manager> element doesn't have anything to do with the session manager. What we really need is a way for Tomcat to understand that it's on windows and automatically use that java.security routine you mentioned. Even a way of setting the filepath as null in the server.xml or context.xml would probably be helpful. Not that it's really that big a deal. Apparantly, from my testing, it only happens twice/context at startup. My real problem is somewhere else. On login, we call request.getSession, which I'm pretty sure is generating a new sessionid (verified by turning off cookies), and thus generating the first PNF. On bad login credentials, we invalidate() the session, which I'm guessing is doing the second PNF. Overall, I'm thinking nothing to worry about, right? Jeff
