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)" <ji...@apache.org> on 2008/03/14 23:10:24 UTC

[jira] Commented: (DERBY-3547) Create a utility that generates a security policy file for Derby's tests

    [ https://issues.apache.org/jira/browse/DERBY-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578944#action_12578944 ] 

Daniel John Debrunner commented on DERBY-3547:
----------------------------------------------

Just to be clear this is a runtime operation for the tests, it's not just a utility to create a lot of static policy files.

Another improvement would be to have defined logical groups of pre-defined permissions that correspond to logical functionality, e.g.

 addPermissionGroup(String group) - add permissions required for the group as needed across code bases.
 removePermissionGroup(String group)  - remove permissions required for the group as needed across code bases.

for items like JMX, code coverage, backup, ...

  addPermissionGroup("jmxclients');

> Create a utility that generates a security policy file for Derby's tests
> ------------------------------------------------------------------------
>
>                 Key: DERBY-3547
>                 URL: https://issues.apache.org/jira/browse/DERBY-3547
>             Project: Derby
>          Issue Type: Improvement
>          Components: Test
>            Reporter: Daniel John Debrunner
>            Priority: Minor
>
> With the number of current test policy files it is becoming a pain to remember to modify all of them when needed to add a new permission.
> In addition with JMX, SystemPermission (and DatabasePermission) support, testing of fine-grained permissions will become unmanagable if a new policy file is needed for every combination.
> I suggest a java utility that can be used in a test decorator to create a set of permissions that can then be modified before creating a real policy file and pointing the security manager to it. I imagine an api like:
> TestPolicy() - constructor creates a set of permissions that corresponds to the current derby_tests.policy (or similar)
> The object supports a number of code bases, corresponding to the current jars, e.g.
>   derby, derbynet, derbytools,derbyclient,ant,emma, junit,
> removeCodebase(String code) - remove all the permissions for a given code base. Allows specific testing, e.g. with just client tests don't have permissions for any other jars.
> removePermission(String code, Permission permission) - remove a single permission from a code base - allows negative testing, what happens if this permission is not available.
> addPermission(String code, Permission permission) - add a permission into the code base
> writePolicyFile(PrintStream out)  - write the policy file out
> This would also stop the need for derby_tests.policy to have a jar and classes section with duplicated information, TestPolicy would just create the grant code blocks with the correct code location.
> TestPolicy could obviously be expanded as new needs appear, eg. Principal testing.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.