Bug 2651

Summary: /dev/random vs. /dev/urandom
Product: Java WS Security Reporter: Mats Rynge <rynge@isi.edu>
Component: AuthenticationAssignee: Rachana Ananthakrishnan <ranantha@mcs.anl.gov>
Status: RESOLVED FIXED    
Severity: major CC: chris@gridwisetech.com, gawor@mcs.anl.gov, gose@mcs.anl.gov, meder@mcs.anl.gov, slang@mcs.anl.gov
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Linux   

Description From 2005-01-27 15:34:26 
Several people have now noticed this:

-----------------------------------------------------------
From: Scott Gose
Subject: [Globus-discuss] container doesn't list services
To: discuss@globus.org
Date: Tue, 25 Jan 2005 20:12:56 -0600

If you start a globus container and it doesn't list the services, but
apparently hangs:

    $ $GLOBUS_LOCATION/bin/globus-start-container
    // it apparently hangs here

Then it's possible you need to set this environment variable:

    export GLOBUS_OPTIONS=-Djava.security.egd=file:/dev/urandom

Jarek pointed me to the fix which works on a host where /dev/random has run
out of entropy and we have to point things to /dev/urandom.

You can test this with:

    $ more /dev/random
    // If it doesn't return stuff, you need the above fix

    $ more /dev/urandom
    // Should return stuff

I experienced this on a Fedora Core 1 machine that has a pretty high uptime
(267 days).

-----------------------------------------------------------


The problem is that there is no warnings about the container stopping (or not
starting at all). This might affect the performance campaigns currently going on.

There should be warnings in the logfile about this.

Also, it would be nice if there was an option allowing the container to fall
back on /dev/urandom in case of /dev/random not being able to deliver the
entropy. It really should be an option, as some people do not want that to happen.
------- Comment #1 From 2005-03-24 14:32:07 ------- 
Just to be a bit more specific, as far as I know this only happens when running
the container with java 1.3.1. So what should be done (if anything) is probably
to add some code to our startup that checks if the java version is 1.3 and if
/dev/urandom exists then it should add is as the entropy source.

/Sam
------- Comment #2 From 2005-03-24 15:16:01 ------- 
Hmm, so what is the default behavior with 1.4.2?

I have a container on a fairly busy host, and used to have problems with it
hanging until we added -Djava.security.egd=file:/dev/urandom. The hanging
stopped around the time we added the option, but maybe it was a coincidence.
------- Comment #3 From 2005-03-24 15:33:51 ------- 
Looks like I got this backwards. 1.4 seems to have /dev/random as the default.
Maybe 1.3 does the correct thing (or I was just confused).

/Sam
------- Comment #4 From 2005-04-05 08:03:58 ------- 
Checked in a patch from the GridWise folks.
------- Comment #5 From 2005-04-21 05:55:19 ------- 
Let me write a few words about solution we chose and implemented.

When the Globus container is about to be start shell script
$GLOBUS_LOCATION/bin/globus-start-container checks if there is /dev/urandom
device  available in the system. If yes, it forces
org.globus.bootstrap.Bootstrap Java class to use this entropy generator. This is
done with java.security.egd Java property. If no, it forces Bootstrap class to
use /dev/random device. 

After having started the container, org.globus.wsrf.container.ServiceContainer
Java class prints logging (log4j) information about the entropy generator it uses.
------- Comment #6 From 2006-09-20 23:03:25 ------- 
See Bug 4721, this configuration requires a URL scheme ("file:" or "file://")