db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bergquist, Brett" <BBergqu...@canoga.com>
Subject RE: Code loaded through SQL.INSTALL_JAR does not have access to derby API code. Is this expected?
Date Tue, 26 Jul 2011 15:11:10 GMT
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.hatlen@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" <BBergquist@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



Mime
View raw message