I opened JIRA issue:
https://issues.apache.org/jira/browse/DERBY-5352
Note that this is also a problem with code implementing the VTICosting
interface. I think the problem is in JarLoader in the code:
// 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;
}
I wonder if some fix was added for security to not allow loaded code to access
the Derby internal code had the unwanted side effect of not allowing access to
the org.apache.derby.vti package. I don't know how to look at the history of
this file, so I cannot be sure. If I add an exception to the above to allow
access to "org.apache.derby.vti", this is no longer a problem.
Looking at the interfaces and classes in the org.apache.derby.vti package,
these seem to be innocuous and probably can be accessed without an security
concerns but this is just a cursory look.
________________________________________
From: Knut Anders Hatlen [knut.hat...@oracle.com]
Sent: Monday, July 25, 2011 2:47 PM
To: derby-dev@db.apache.org
Cc: Bergquist, Brett
Subject: Re: Code loaded through SQL.INSTALL_JAR does not have access to derby
API code. Is this expected?
"Bergquist, Brett" <bbergqu...@canoga.com> writes:
> I found some information. I found that if I include my JAR file
> containing my Restricted Table code in the classpath before starting
> the network server, then the code can load correctly and it has access
> to the "org.apache.derby.vti.RestrictedVTI" class and others. If
> however the code is loaded through the SQLJ.INSTALL_JAR procedure,
> then the code does not have access to the
> "org.apache.derby.vti.RestrticedVTI" class or others.
>
> Is this expected? I really would like to be able to install my table
> function code to be in the database and not have to manipulate the
> classpath. No where in the documentation does it say that this cannot
> be done, but it does not work.
>
> Should I write up an issue in JIRA?
I think this is intended to work, so a JIRA issue would be in order.
This bug looks somewhat related:
https://issues.apache.org/jira/browse/DERBY-4126
In that bug, we had to make the VTICosting interface available for the
procedures. I guess we'll need a similar trick for RestrictedVTI.
--
Knut Anders
