I will fax a signed CLA tonight EST.
-----Original Message-----
From: Rick Hillegas (JIRA) [mailto:[email protected]]
Sent: Tuesday, August 02, 2011 2:36 PM
To: [email protected]
Subject: [jira] [Commented] (DERBY-5352) Derby table functions stored in a jar
file inside the database which implement VTICosting or RestrictedVTI fail with
ClassNotFoundException
[
https://issues.apache.org/jira/browse/DERBY-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078350#comment-13078350
]
Rick Hillegas commented on DERBY-5352:
--------------------------------------
All regression tests passed cleanly for me. This patch is ready for commit once
we clear up the CLA issue. Thanks.
> Derby table functions stored in a jar file inside the database which
> implement VTICosting or RestrictedVTI fail with ClassNotFoundException
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5352
> URL: https://issues.apache.org/jira/browse/DERBY-5352
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.8.1.2
> Reporter: Brett Bergquist
> Attachments: derby-5352-01-ab-fixWithRegressionTest.diff,
> derby-5352.diff
>
>
> Derby table functions stored in a jar file inside the database which
> implement VTICosting or RestrictedVTI fail with ClassNotFoundException. This
> occurs when you attempt to query the table function. If you put the JAR on
> the classpath instead, then the table function can be accessed correctly.
> I believe the problem is in JarLoader.java which has:
> // Classes in installed jars cannot reference
> // Derby internal code. This is to avoid
> // code in installed jars bypassing SQL
> // authorization by calling Derby's internal methods.
> //
> // Any classes in the org.apache.derby.jdbc package
> // are allowed as it allows routines to make JDBC
> // connections to other databases. This does expose
> // public classes in that package that are not part
> // of the public api to attacks. One could attempt
> // further limiting allowed classes to those starting
> // with Embedded (and Client) but when fetching the
> // default connection in a routine (jdbc:default:connection)
> // the DriverManager attempts a load of the already loaded
> // AutoloadDriver, I think to establish the calling class
> // has access to the driver.
> //
> // This check in addition to the one in UpdateLoader
> // that prevents restricted classes from being loaded
> // from installed jars. The checks should be seen as
> // independent, ie. the restricted load check should
> // not make assumptions about this check reducing the
> // number of classes it has to check for.
> if (className.startsWith("org.apache.derby.")
> && !className.startsWith("org.apache.derby.jdbc."))
> {
> ClassNotFoundException cnfe = new
> ClassNotFoundException(className);
> //cnfe.printStackTrace(System.out);
> throw cnfe;
> }
> Which explicitly restricts access to the org.apache.derby package except for
> org.apache.derby.jdbc. I have debugged this and if change this to:
> // Classes in installed jars cannot reference
> // Derby internal code. This is to avoid
> // code in installed jars bypassing SQL
> // authorization by calling Derby's internal methods.
> if (className.startsWith("org.apache.derby.")
> && !className.startsWith("org.apache.derby.jdbc.")
> && !className.startsWith("org.apache.derby.vti."))
> {
> ClassNotFoundException cnfe = new
> ClassNotFoundException(className);
> //cnfe.printStackTrace(System.out);
> throw cnfe;
> }
> The access is allowed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
