db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5611) Permissions granted by server.policy to derbytools.jar are not sufficient to run ij
Date Mon, 13 Feb 2012 15:30:59 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206932#comment-13206932

Knut Anders Hatlen commented on DERBY-5611:

Why would the server need to run ij?

It looks like the permissions granted to derbytools.jar (and derbyclient.jar) are there for
the sysinfo code, which lives in all the jar files so that you don't know from which jar file
the classes are loaded. The network server calls into sysinfo code from NetworkServerControlImpl.getCLSSysInfo(),
so option 1 might cause problems for that method if derbytools.jar is first in classpath.
> Permissions granted by server.policy to derbytools.jar are not sufficient to run ij
> -----------------------------------------------------------------------------------
>                 Key: DERBY-5611
>                 URL: https://issues.apache.org/jira/browse/DERBY-5611
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server, Tools
>    Affects Versions:
>            Reporter: Rick Hillegas
>            Priority: Minor
> server.policy grants derbytools.jar the permission to read several system properties.
 However, at startup ij tries to read all of the system properties. This happens in ij.jj
in the initFromEnvironment() method. To call System.getProperties(), you need the following
>   permission java.util.PropertyPermission "*", "read,write";
> ij startup fails with this error trace:
> Exception in thread "main" java.security.AccessControlException: access denied (java.util.PropertyPermission
* read,write)
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
> 	at java.security.AccessController.checkPermission(AccessController.java:546)
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> 	at java.lang.SecurityManager.checkPropertiesAccess(SecurityManager.java:1252)
> 	at java.lang.System.getProperties(System.java:581)
> 	at org.apache.derby.impl.tools.ij.ij$1.run(ij.java:113)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.apache.derby.impl.tools.ij.ij.initFromEnvironment(ij.java:111)
> 	at org.apache.derby.impl.tools.ij.utilMain.initFromEnvironment(utilMain.java:175)
> 	at org.apache.derby.impl.tools.ij.Main.<init>(Main.java:244)
> 	at org.apache.derby.impl.tools.ij.Main.getMain(Main.java:196)
> 	at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181)
> 	at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
> 	at org.apache.derby.tools.ij.main(ij.java:59)
> Here are some ways to fix this problem:
> 1) Remove the whole block of permissions for derbytools.jar. Maybe those permissions
don't belong in server.policy. Note that a similar block of permissions also appears in template.policy
with a comment suggesting that they are sufficient for running the Derby tools.
> 2) Add to the derbytools block the missing permission.
> 3) Re-write initFromEnvironment() so that it reads only a few properties rather than
all properties.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message