db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Security Manager Testing coverage if user code does not have access to the database directory
Date Wed, 09 Aug 2006 14:03:35 GMT
I am working on an issue with an old version of  Cloudscape where 
creating a table  under security manager fails unless the user code is 
given read access to the database directory.  What I found was that the 
test case:

- Failed with Cloudscape 5.1.60 on create table unless I added read 
permissions for the database directory with:
    java.security.AccessControlException: access denied 
(java.io.FilePermission C:\db\test\seg0 read)

- Regressed Further with 10.0.2.2.349072  and failed even with read 
permissions on the database directory with:
    ERROR XBM02: Startup failed due to missing functionality for 
org.apache.derby.iapi.services.stream.InfoStreams.
   (Not sure what the issue was here, but granting all permissions to 
user code did the trick #:)

- Passes with 10.1.3.1 - (417277)   and 10.2.0.5 - (429411)

Looking at our  derby_tests.policy I don't think this case where the 
user code does not have read access to the database is covered because 
we have this:
 
  // Access all files under ${user.dir}to write the test directory structure
  permission java.io.FilePermission "${user.dir}${/}-", "read,write,delete";

which I think includes the database directory.  Is that correct?

I was thinking I would  make a Jira issue to cover the case where the  
user code does not have read access to the database directory but wanted 
to check that I understood this correctly.  Also I understand that given 
our current harness, this might be a difficult change, but was wondering 
if it might be more feasible in the JUnit world.

Below is the test case information for those with more than the typical 
interest.  Again this all passes fine now with Derby 10.1.3.1. This is 
just a question of test coverage.


Thanks

Kathey

ij> connect 'jdbc:derby:c:/db/test;create=true';
ij> CREATE TABLE TESTTABLE2 (COL INT);
0 rows inserted/updated/deleted

java -Dcodebase=C:/marsden/releases/10.2.0.5.429411 
-Djava.security.manager -Djava.security.policy=my.policy 
test.DerbySecurityTest
started
Executing statement: INSERT INTO TESTTABLE2 VALUES (37)
Executing statement: CREATE TABLE TESTTABLE (C INT)
Executing statement: DROP TABLE TESTTABLE
done
$

my.policy

// permissions for derby  code base:
grant codeBase "file:${codebase}/-" {
  permission java.security.AllPermission;
};
// No permissions for user code.

DerbySecurityTest

/*
 * Created on Aug 2, 2006
 *
 */
package test;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;
import java.sql.SQLException;

public class DerbySecurityTest {

    public static void main(String[] args) throws Exception{
        try {
            System.out.println("started");
            String dbName = "jdbc:derby:c:/db/test";
            if (args.length > 0) {
                dbName = args[0];
            }

            Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
            Connection conn = DriverManager.getConnection(dbName);
            String[] statements = new String[] { "INSERT INTO TESTTABLE2 
VALUES (37)", "CREATE TABLE TESTTABLE (C INT)", "DROP TABLE TESTTABLE" };
            for (int i = 0; i < statements.length; i++) {
                System.out.println("Executing statement: " + statements[i]);
                final String statementString = statements[i];
                final Statement stat = conn.createStatement();
                stat.execute(statementString);
            }
            System.out.println("done");
        } catch (SQLException  exc) {
            do {
                exc.printStackTrace();
                exc = exc.getNextException();
            } while (exc != null);
        }
    }
}




Mime
View raw message