[ https://issues.apache.org/jira/browse/DERBY-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078739#comment-13078739 ]
Rick Hillegas commented on DERBY-5352: -------------------------------------- Ported 1153474 from the trunk to the 10.8 branch at subversion revision 1153478. > 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