SecurityManager testing

Update

Most of this document is written before the work was started, now most of the tests run under the SecurityManager. Further down in this document you can see the state per test suite.

Overview

Currently any test that runs the network server as a separate java executable uses the security manager and a policy file (nwsvr.policy) for the network server's JVM. This is a good step but I (Dan Debrunner) have been looking to improve the situation to run most tests under the security manager (by default). Discussion is under this thread http://mail-archives.apache.org/mod_mbox/db-derby-dev/200510.mbox/%3c434946C8.6000706@debrunners.com%3e

Goal

My goal is to ensure that running derbyall tests all Derby's functionality works with a security manager and a correctly, minimally configured policy file. By minimally I mean just the fewset set of permissions required, hopefully in-line with the documentation. E.g. a policy file that allowed all permissions would work but would not be a good test of Derby.

Current Behaviour

The harness determins a code base from the class path and sets this as the property csinfo.codebase for the policy file. This code base will correspond to either the classes directory or the directory containing derby jar files. The policy file (nwsvr.policy) then has a set of permissions that are granted to the code base, which is the entire derby code.

Issue with the current behaviour

Granting permissions to a single code base that includes all the derby code can lead to hidden bugs, especially due to the fact the test harness does not need to be secure and is not designed that way, whereas the other derby components need to be secure. For example, the test harness needs to read and modify system properties so that permission is granted, now the engine should not be needing that permission but due to the single code base in the policy file, it has that permission and now silently could start to depend on it.

Proposed change

I have a more specific properties file (derby_tests.policy) that has a section for each derby jar file with code, and grants only the required (and reasonable) permissions for each jar. E.g. derby.jar is not granted any socket related permissions and derbynet.jar is not granted any access to the database files. With this file incorrect permissions that need to be granted are obvious and bugs can be entered against them.

In addition a section in the policy file will exist for the classes directory with a superset of the permissions. This is for when the tests are run directly out of the classes directory.

There is a chance that the tests will pass under the classes and fail with the jars with a contribution or change. The risk is small (and most likely would point to a bug). Comments can be added in the policy file indicating if changes are made to the classes section that similar changes might be needed to the jar sections and tests should also be run using the jars.

Justification

I strongly believe that the single code base approach today is not sufficent for Derby's security testing, due to the potential for hidden bugs. In switching to this new style I think I've found three bugs so far against Derby related to permissions, including one potentially serious one where a create index fails due to no access to a temp file. I need to look at that one more. I think the number of bugs (so far) shows the change is a good one.

Status

Table of tests running under the SecurityManager by suite.

• Test JVM - JVM running the JDBC/ij test
• Network Server JVM - JVM running the network server when the client is in a separate JVM.
  

Values in the columns represent the number of tests running using the SecurityManager out of the total for the suite. Counts may be approximate.

Progress Table