Bug 46967 - ManagerBase.setRandomFile error handling fix
Summary: ManagerBase.setRandomFile error handling fix
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.27
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
: 47276 (view as bug list)
Depends on:
Reported: 2009-04-03 18:57 UTC by Kirk Wolf
Modified: 2009-08-12 18:23 UTC (History)
2 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Kirk Wolf 2009-04-03 18:57:28 UTC
On some platforms (z/OS for sure), the device file /dev/urandom can pass the "f.exists()" test, but throws an IOException of some kind when trying to open it.  The current code in ManagerBase.setRandomFile() doesn't handle this, which results in EVERY call to getRandom() to try again and log the error  "Failed to close randomIS".

The following changes to the method will add proper error handling to correct this (my changes marked "// kjw")

    public void setRandomFile( String s ) {
        // as a hack, you can use a static file - and genarate the same
        // session ids ( good for strange debugging )
        if (Globals.IS_SECURITY_ENABLED){
            randomIS = (DataInputStream)AccessController.doPrivileged(new PrivilegedSetRandomFile());          
        } else {
                File f=new File( devRandomSource );
                if( ! f.exists() ) return;
                randomIS= new DataInputStream( new FileInputStream(f));
                if( log.isDebugEnabled() )
                    log.debug( "Opening " + devRandomSource );
            } catch( IOException ex ) {
            	log.debug("Error reading " + devRandomSource, ex); //kjw
            	if (randomIS != null) {  // kjw: if opened
	                try {
	                } catch (Exception e) {
	                    log.warn("Failed to close randomIS.");
            	}                       // kjw 
            	devRandomSource = null; // kjw: don't try again automatically
Comment 1 Mark Thomas 2009-04-08 06:02:07 UTC
Thanks for the patch. I have applied it to trunk and proposed it for 6.0.x.

I extended your patch to make the behaviour consistent when running under a security manager.
Comment 2 Mark Thomas 2009-05-22 08:15:11 UTC
This has been fixed in 6.0.x and will be in 6.0.21 onwards.
Comment 3 Konstantin Kolinko 2009-07-17 10:41:58 UTC
*** Bug 47276 has been marked as a duplicate of this bug. ***
Comment 4 Konstantin Kolinko 2009-07-17 10:45:26 UTC
Reopening, to track fixing it in 5.5 branch.
Comment 5 Konstantin Kolinko 2009-08-12 18:23:28 UTC
This has been fixed in 5.5 and will be in 5.5.29 onwards.