Security Manager Testing coverage if user code does not have access to the database directory

[Kathey Marsden <km...@sbcglobal.net>]

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);
        }
    }
}

Re: Security Manager Testing coverage if user code does not have access to the database directory

[Kathey Marsden <km...@sbcglobal.net>]

Daniel John Debrunner wrote:

> someone (I
>think you) had already prepared it by running the network server under
>the security manager.
>
>  
>
You know since you brought this up, I have an ancient history question 
for you.    I did put that in many years ago.
At the time I  thought network server offered a good framework for 
testing  under security manager because we could start the server with 
restricted permissions and then get  some security manager coverage for 
Derby embedded through Network Server.    As you started working on 
bringing embedded on-line and getting the specific jar permissions 
separated, you had indicated that really the old network server testing  
didn't add much in terms of coverage, but I was always very confused by 
that, because looking back at the policy file, I see that permissions 
were restricted on the server side and I do recall the effort popping 
several bugs.  Still, I think I must have a core misunderstanding of  
security manager and wonder if you might be willing to elaborate your 
assessment  for my edification.

Thanks

Kathey

Re: Security Manager Testing coverage if user code does not have access to the database directory

[Daniel John Debrunner <dj...@apache.org>]

Kathey Marsden wrote:

> Daniel John Debrunner wrote:
> 
>> We have however come a long way from when no tests were run
>> under the security manager. :-)
>>
>>  
>>
> Absolutely!  I really appreciate your arduous incremental work on the
> security manager testing.

It's been a community effort, I was finding bugs but many others were
fixing them. I was only inspired to fry the fish because someone (I
think you) had already prepared it by running the network server under
the security manager.

Dan.

Re: Security Manager Testing coverage if user code does not have access to the database directory

[Kathey Marsden <km...@sbcglobal.net>]

Daniel John Debrunner wrote:

>We have however come a long way from when no tests were run
>under the security manager. :-)
>
>  
>
Absolutely!  I really appreciate your arduous incremental work on the 
security manager testing.  Security Manager regression tests are 
extremely important because this, IMHO,  is a very regression prone 
area.  The regression  from 5.1.60 to 10.0 is clear evidence of that.

>The case is covered by any JUnit test.
>
Excellent.  This is what I was hoping.

>I think we could do better by not granting permissions to derbytools and
>derbytesting.jar to read the database files. I think the natural way
>forward on this would be in the JUnit world and to have a standard
>consistent layout.
>

Sounds  good. 
Should I file a Jira issue to change permissions for JUnit testing to 
exclude  database file permissions for derbytools.jar and 
derbytesting.jar or is that already part of some existing issue/plan?

Thanks

Kathey

Re: Security Manager Testing coverage if user code does not have access to the database directory

[Daniel John Debrunner <dj...@apache.org>]

Kathey Marsden wrote:

> 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.

The test case is covered today, though I think you bring out a good
point that we could do better. Running the JUnit tests today outside of
the derby test harness exposes a couple of minor security manager issues
with ij, so we should always be looking for ways to make the testing
better. We have however come a long way from when no tests were run
under the security manager. :-)

The case is covered by any JUnit test since only a couple of minor
permission are granted to the JUnit code, and they do not include access
to the database files.

I think we could do better by not granting permissions to derbytools and
derbytesting.jar to read the database files. I think the natural way
forward on this would be in the JUnit world and to have a standard
consistent layout. Something like.

${derby.system.home}
Access only given to derby.jar/derbynet.jar, derbytools should not be
reading files in the system home, derbytesting should only be able to
access limited files, such as derby.log and derby.properties. The value
of derby.system.home must not fall under any of the following folders,
e.g. for the default case ${user.dir}/dsh would be good.

${user.dir}/databases
   All databases created under this folder when derby.system.home is not
set, access would only be granted to derby.jar

${user.dir}/extin,extout,extinout
   Access granted as today

${user.dir}/tests
   Folder test scripts, fail logs etc. permissions granted to
derbytesting, maybe derbytools but not derby.jar & derbynet.jar


Dan.