[
https://issues.apache.org/jira/browse/DERBY-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16658265#comment-16658265
]
Rick Hillegas commented on DERBY-3547:
--------------------------------------
A first step toward simplifying our policy files is to create a tool to verify
that revamped, generated policies are equivalent to the old hard-coded
policies. Attaching SecurityPolicyVTI. This is a table function which prints
out the contents of a security policy. Compile it with Java 11. The following
script shows how to use this tool:
{noformat}
connect 'jdbc:derby:memory:db;create=true';
create function securityPolicy(policyFileName varchar( 32672 ))
returns table
(
grant_target varchar( 32672 ),
permission varchar( 32672 )
)
language java parameter style derby_jdbc_result_set no sql
external name 'SecurityPolicyVTI.securityPolicy';
select
cast(grant_target as varchar(50)) as grant_target,
cast (permission as varchar(100)) as permission
from table
(
securityPolicy('/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.server/org/apache/derby/drda/server.policy')
) tr;
{noformat}
> 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
> Attachments: SecurityPolicyVTI.java
>
>
> 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 was sent by Atlassian JIRA
(v7.6.3#76005)
