You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <de...@db.apache.org> on 2006/08/09 18:57:14 UTC
[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.
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
[jira] Commented: (DERBY-1656) Define & implement directory
structure for JUnit tests to allow clear separation of security access for
derby testing and product jar files.
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1656?page=comments#action_12439973 ]
Daniel John Debrunner commented on DERBY-1656:
----------------------------------------------
Policy being fleshed out in:
http://wiki.apache.org/db-derby/DerbyJunitTestConfiguration
> Define & implement directory structure for JUnit tests to allow clear separation of security access for derby testing 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 'wombat1' 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
[jira] Updated: (DERBY-1656) Define & implement directory structure
for JUnit tests to allow clear separation of security access for derby
testing and product jar files.
Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1656?page=all ]
Kristian Waagan updated DERBY-1656:
-----------------------------------
Summary: Define & implement directory structure for JUnit tests to allow clear separation of security access for derby testing and product jar files. (was: Define & implement direcory structure for JUnit tests to allow clear separation of security access for derby tetsing and product jar files.)
Description:
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 'wombat1' 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.
was:
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.
Fixed a few typos; buggy fingers or a buggy T key on the keyboard :)
> Define & implement directory structure for JUnit tests to allow clear separation of security access for derby testing 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 'wombat1' 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