Bug 46967

Summary: ManagerBase.setRandomFile error handling fix
Product: Tomcat 5 Reporter: Kirk Wolf <kirk>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: normal CC: tfull, Tim.Whittington
Priority: P2    
Version: 5.5.27   
Target Milestone: ---   
Hardware: All   
OS: All   

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 {
            try{
                devRandomSource=s;
                File f=new File( devRandomSource );
                if( ! f.exists() ) return;
                randomIS= new DataInputStream( new FileInputStream(f));
                randomIS.readLong();
                if( log.isDebugEnabled() )
                    log.debug( "Opening " + devRandomSource );
            } catch( IOException ex ) {
            	log.debug("Error reading " + devRandomSource, ex); //kjw
            	if (randomIS != null) {  // kjw: if opened
	                try {
	                    randomIS.close();
	                } catch (Exception e) {
	                    log.warn("Failed to close randomIS.");
	                }
            	}                       // kjw 
            	devRandomSource = null; // kjw: don't try again automatically
                randomIS=null;
            }
        }
    }
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.