I am not sure why - I think, however, that there's something happening with the derby_tests.policy file. It grants the following:
 
  // Access all properties using System.getProperties
  permission java.util.PropertyPermission "*", "read, write";
.....
 
to codeclasses, derbyTesting.jar and derbytools.jar.
 
However, sysinfo, accessing java.class.path, lives in both derbytools.jar and derby.jar and also in derbynet.jar. So, I imagine, when running with jars, if derby.jar is first in the classpath, that will be the sysinfo that is being picked up, and so, it can't access java.class.path.
 
I do not know if it would be ok to always (i.e., for derby.jar) grant access to that specific property. Would that pose a security risk in some way?
 
Myrna
 
On 3/24/06, Bryan Pendleton <[EMAIL PROTECTED]> wrote:
> 4) My classpath is wired together out of the classtree under
> trunk/classes and the jar files in trunk/tools/java.

Thanks, Rick, that was exactly the clue I needed.

I've been running solely from jars, both sane and insane.

When I re-wired my classpath to run directly from trunk/classes,
I got exactly the error you describe.

Rick, can you file a bug and assign it to me?

Meanwhile, can some of the security experts help me out a bit
with the policy file? Why is it that the sysinfo code is
permitted to read the java.class.path property when running
from the classes directory, but is denied access to that property
when running from jars?

thanks,

bryan




Reply via email to