[
https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543645
]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
Thanks for the quick feedback, Dan.
The server policy file grants permissions to derbytools, derbyclient, and
derbyTesting in order to fix DERBY-3086. The problem is that we don't control
the order in which jar files are wired into the classpath. Unfortunately,
sysinfo lives in all of those jar files and the permissions it needs must be
granted to the first of those jar files which appears on the classpath.
I don't understand how the property setting could be intercepted. That would
involve injecting malicious code into
NetworkServerControl.installSecurityManager() just after the properties are
forcibly set and just before the SecurityManager is installed. These are
properties which are private to Derby and which we don't allow the user to
override. Could you explain more about how the property setting could be
intercepted?
The security hole I see is if the customer repackages the jar files, perhaps
folding them into a master jar file which contains application code. In that
case the proposed scheme would end up granting all of Derby's permissions to
application code. For the record, the same subversion can occur with the scheme
we have today: The customer just needs to put application code into derby.jar.
> Network server demands a file called "derbynet.jar" in classpath
> ----------------------------------------------------------------
>
> Key: DERBY-3083
> URL: https://issues.apache.org/jira/browse/DERBY-3083
> Project: Derby
> Issue Type: Bug
> Components: Tools
> Affects Versions: 10.3.1.4
> Reporter: Aaron Digulla
> Attachments: derby-716-10-datatypesCollation-aa.diff
>
>
> The network server will not start if the derbynet jar is added under a
> different name than "derbynet.jar" to the classpath. This makes it impossible
> to use it in maven projects where the jar is renamed to
> "derbynet-10.3.1.4.jar".
> This did work with 10.2.2.0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
