db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Created: (DERBY-1656) Define & implement direcory structure for JUnit tests to allow clear separation of security access for derby tetsing and product jar files.
Date Wed, 09 Aug 2006 16:57:14 GMT
Define & implement direcory structure for JUnit tests to allow clear separation of security
access for derby tetsing and product jar files.
-------------------------------------------------------------------------------------------------------------------------------------------

                 Key: DERBY-1656
                 URL: http://issues.apache.org/jira/browse/DERBY-1656
             Project: Derby
          Issue Type: Improvement
          Components: Test
            Reporter: Daniel John Debrunner


Discussion in this thread highlights the risk with the current (old test harness) approach
of granting access to the testing code (the user application) to read the database files themselves.

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200608.mbox/%3c44D9EB37.6020503@sbcglobal.net%3e

Policy suggested is:

${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


Note that ideally tests should not be written to assume anything about the database name or
its location, that way we could have multiple sets of Junit tests running in parallel, e.g.
one against database  'womba1t' in ${derby.system.home}, one against  databases/wombat2 in
${user.dir}.
Eventually the same would apply for multiple derby systems in different classloaders (DERBY-700),
 so any scheme should take these desires into account.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message