db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Security Manager Testing coverage if user code does not have access to the database directory
Date Wed, 09 Aug 2006 14:43:27 GMT
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.



Mime
View raw message