Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1ACE86ECB for ; Tue, 2 Aug 2011 16:31:53 +0000 (UTC) Received: (qmail 7246 invoked by uid 500); 2 Aug 2011 16:31:52 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 7042 invoked by uid 500); 2 Aug 2011 16:31:52 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 7033 invoked by uid 99); 2 Aug 2011 16:31:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Aug 2011 16:31:52 +0000 X-ASF-Spam-Status: No, hits=-2000.7 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Aug 2011 16:31:49 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 5B51E99402 for ; Tue, 2 Aug 2011 16:31:27 +0000 (UTC) Date: Tue, 2 Aug 2011 16:31:27 +0000 (UTC) From: "Rick Hillegas (JIRA)" To: derby-dev@db.apache.org Message-ID: <547657157.1937.1312302687370.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1521600591.7708.1311692231544.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (DERBY-5352) Derby table functions stored in a jar file inside the database which implement VTICosting or RestrictedVTI fail with ClassNotFoundException MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13076298#comment-13076298 ] Rick Hillegas commented on DERBY-5352: -------------------------------------- Running full regression tests now. > 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