> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, August 29, 2012 4:05 PM > To: Tomcat Users List > Subject: Re: Windows Path Not Found for urandom > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jeff, > > On 8/29/12 4:54 PM, Jeffrey Janner wrote: > > Looking at that code, it looks like the only way to set the file is > > to change it there and recompile. > > Not at all: you should be able to configure the Manager by setting > attributes on the <Manager> element in your context.xml. If you don't > already have one, add one and then set the randomFile attribute to > whatever you want. > > > The <manager> element doesn't have anything to do with the session > > manager. > > Er, it has everything to do with it. <Manager> configures the session > manager. If you don't believe me, read the documentation and/or the > code. > [Jeff Janner] OOPs, temporarily confused the manager app with the <manager> element. I'll give setting a null path a try and see what happens.
> > 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. > > It will. You created a zero-length file in C:\dev\urandom and it's > causing a one-time error message. Don't do that! > > > Even a way of setting the filepath as null in the server.xml or > > context.xml would probably be helpful. > > You could do that, or you could set it to a path that points to > nothing. > Under normal circumstances, you wouldn't find a C:\dev\urandom file in > a Microsoft Windows environment, so the default automatically falls- > back to java.security.SecureRandom. Why don't you just remove that > file? [Jeff Janner] I did delete the file. It was just a test at Konstantin's suggestion to see what would happen. If you go back to the beginning of the thread, this started 'cause I had a customer that was monitoring Tomcat and they were seeing all these PNFs and freaking out about it. I was looking for a way to calm them down. On the plus side, I'm now positive the PNFs weren't/don't come from the OpenSSL code. > > > Not that it's really that big a deal. Apparently, from my testing, > it > > only happens twice/context at startup. > > It should happen once, but I suppose anything is possible -- especially > if you have an ... odd deployment configuration. > [Jeff Janner] I assumed twice/context, because that is how many PNFs I see with the file missing (as it should be under windows). This is just at startup, before any client access attempts. > > 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. > > Invalidating the session shouldn't require any entropy to be read, so I > wouldn't expect any failure. > [Jeff Janner] I wouldn't think so either. What I should have said was, we call session.invalidate() and then generate an error page. Maybe it's something in the error page code that's generating the second PNF. > > Overall, I'm thinking nothing to worry about, right? > > If I were you, I'd delete the file and move on with my life: the error > message will go away and otherwise the system will operate exactly as > before. > > - -chris The PNFs won't go away, and that really is my ultimate goal. Of course, you only see them if you're a paranoid individual running a process monitoring tool. The real thing is under Windows, Tomcat shouldn't be looking for a /dev/urandom file, or anything equivalent since it doesn't exist. So it spends a few cycles looking for it anytime it thinks it needs it, when really it should just not even look for it, or look for it once and remember it doesn't have one. Personally, I can live with wasting a few cycles, but can everyone?
