You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (Commented) (JIRA)" <ji...@apache.org> on 2012/02/13 16:30:59 UTC

[jira] [Commented] (DERBY-5611) Permissions granted by server.policy to derbytools.jar are not sufficient to run ij

    [ 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: 10.9.0.0
>            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:
>   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