RE: Code loaded through SQL.INSTALL_JAR does not have access to derby API code. Is this expected?
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
RE: Code loaded through SQL.INSTALL_JAR does not have access to derby API code. Is this expected?
So it seems that DERBY-2331 disables access to org.apache.derby.* namespace
but the comment says except for public apis. It seems to me that the
RestrictedVTI and VTICosting are public API's now.
From: Bergquist, Brett [bbergqu...@canoga.com]
Sent: Tuesday, July 26, 2011 11:11 AM
To: Knut Anders Hatlen; derby-dev@db.apache.org
Subject: RE: Code loaded through SQL.INSTALL_JAR does not have access to derby
API code. Is this expected?
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
RE: Code loaded through SQL.INSTALL_JAR does not have access to derby API code. Is this expected?
So in UpdateLoader.java there is:
private static final String[] RESTRICTED_PACKAGES = {
// While loading java. classes is blocked by the standard
// class loading mechanism, javax. ones are not. However
// allowing database applications to override jvm classes
// seems a bad idea.
javax.,
// Allowing an application to possible override the engine's
// own classes also seems dangerous.
org.apache.derby.,
};
Will this prevent any user functions or procedures such as a table function
from accessing org.apache.derby.vti.RestrictedVTI? This seems to prevent
Restricted Table functions from being loaded jar files stored in the database.
From: Bergquist, Brett
Sent: Monday, July 25, 2011 12:44 PM
To: Bergquist, Brett; derby-dev@db.apache.org
Subject: Code loaded through SQL.INSTALL_JAR does not have access to derby API
code. Is this expected?
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?
From: Bergquist, Brett
Sent: Monday, July 25, 2011 9:23 AM
To: Bergquist, Brett; derby-dev@db.apache.org
Subject: Re: Problem in trying to get a Restricted Table Function loaded
In case this got missed as I could really use the help. Just need to know what
I need to do to get the VYI classes to be accessible to my table function. As
a straight table function it registers and works fine but as soon as I
reference something like VTITemplate it fails saying it could not find the
class.
Brett Bergquist
Principal Software Engineer
Phone: 203 888 7914 Ext 204
Email: bbergqu...@canoga.com
- Reply message -
From: Bergquist, Brett bbergqu...@canoga.com
Date: Sun, Jul 24, 2011 11:19 am
Subject: Problem in trying to get a Restricted Table Function loaded
To: derby-dev@db.apache.org derby-dev@db.apache.org
My class looks like:
public class NpaResultsTableFunction extends VTITemplate implements
RestrictedVTI {
public static NpaResultsTableFunction read() throws SQLException {
return new NpaResultsTableFunction();
}
public NpaResultsTableFunction() throws SQLException {
conn = DriverManager.getConnection(jdbc:default:connection);
}
...
}
I have defined the function using the following where csem-pcs-derby-jar is
the location of the JAR file containing this table function:
CALL SQLJ.INSTALL_JAR('${csem-pcs-derby-jar}',
'PCS_V1.pcsderby', 0);
SET SCHEMA PCS_V1;
CREATE FUNCTION NPARESULTS_TABLE () RETURNS TABLE
(org.apache.derby.vti.RestrictedVTI
ID BIGINT,
REPORTKEY CHAR(56),
MASTERIP CHAR(4) FOR BIT DATA,
BOOTCOUNT INTEGER,
TESTRESULTID BIGINT,
PROFILEREFID INTEGER,
ADDRESSREFID INTEGER,
STARTDATETIME TIMESTAMP,
ACCURACYLEVEL SMALLINT,
RESULTFLAG SMALLINT,
PACKETSSENT INTEGER,
ROUNDTRIPPACKETS INTEGER,
DROPPEDPACKETS INTEGER,
OUTOFORDERPACKETS INTEGER,
MINROUNDTRIPLATENCY INTEGER,
MAXROUNDTRIPLATENCY INTEGER,
TOTALROUNDTRIPLATENCY BIGINT,
AVGROUNDTRIPLATENCY INTEGER,
LATENCYBUCKETVALUE1 INTEGER,
LATENCYBUCKETVALUE2 INTEGER,
LATENCYBUCKETVALUE3 INTEGER,
LATENCYBUCKETVALUE4 INTEGER,
LATENCYBUCKETVALUE5 INTEGER,
LATENCYBUCKETVALUE6 INTEGER,
LATENCYBUCKETVALUE7 INTEGER,
LATENCYBUCKETVALUE8 INTEGER,
LATENCYBUCKETVALUE9 INTEGER,
LATENCYBUCKETVALUE10 INTEGER,
JITTERMEASUREMENT INTEGER,
MINLOCALREMOTEJITTER INTEGER,
MAXLOCALREMOTEJITTER INTEGER,
TOTALLOCALREMOTEJITTER BIGINT,
AVGLOCALREMOTEJITTER INTEGER,
LOCALREMOTEJITTERBUCKETVALUE1 INTEGER,
LOCALREMOTEJITTERBUCKETVALUE2 INTEGER,
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
