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

["Rick Hillegas (JIRA)" <ji...@apache.org>]

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

Rick Hillegas commented on DERBY-3547:
--------------------------------------

Attaching derby-3547-01-ab-policyGenerator.diff. This patch introduces a security policy generator. The generator lets us declare various security policies as deltas from parent policies. This patch was used to generate the new Security Guide template policies, which were checked in by derby-6980-03-aa-securityPolicies.diff. I will run tests with both the classpath and the module path.

This patch makes the following changes:

1) Introduces a new SecurityPolicyGenerator tool. The tool reads securityPolicies.xml, a file which describes policies as deltas from parent policies. The SecurityPolicyGenerator then writes valid policy files into the generated directory tree and into the classes tree.

2) Removes the source versions of server.policy and derby_tests.policy. Those policies are now created by SecurityPolicyGenerator.

3) In addition to writing server.policy and derby_tests.policy, the SecurityPolicyGenerator also writes the DITA source pages for the template and example policy files which appear in the Security Guide.

4) Wires the SecurityPolicyGenerator into the compilation phase of the Derby build.

5) Adds a new target to the top level build file. The new target copies the generated DITA source from the code tree into the docs tree. The target can be called standalone. It is also wired into the release build so that documented policy file templates and examples will be kept up-to-date whenever we build a release candidate.

In follow-on patches, I plan to replace the dozens of test policy files with descriptors in securityPolicies.xml. They can then be generated as deltas from one another.

Touches the following files:

{noformat}
--------------------------------

M       java/build/org/apache/derbyBuild/MessageBuilder.java
A       java/build/org/apache/derbyBuild/SecurityPolicyGenerator.java

This is the policy-generating tool. It re-uses some of
MessageBuilder's machinery for reading/writing xml.

--------------------------------

A       java/org.apache.derby.engine/org/apache/derby/security/securityPolicies.dtd
A       java/org.apache.derby.engine/org/apache/derby/security/securityPolicies.xml

securityPolicies.xml is the input to
SecurityPolicyGenerator. securityPolicies.xml describes the policies
which will be generated and clarifies how policies extend and modify
one another.

securityPolicies.dtd describes the xml grammar used to decribe policy
files. An extensive header comment explains the grammar and the
process of generating policies from descriptors.

--------------------------------

A       java/org.apache.derby.engine/org/apache/derby/security/securityDocExample.properties
A       java/org.apache.derby.engine/org/apache/derby/security/securityProduct.properties
A       java/org.apache.derby.engine/org/apache/derby/security/securityTests.properties

The grant targets in securityPolicies.xml are logical
names. These logical names need to be changed into physical names when
generating policy files. The physical names specify where the
grant targets actually live in the file system. 3 mappings of logical
to physical names are provided:

o securityProduct.properties - This mapping describes where grant
targets live in server.policy.

o securityTests.properties - This mapping describes where grant
targets live in the test policies.

o securityDocExample.properties - This mapping describes where grant
targets live in the Security Guide's sample policy file.

--------------------------------

M       java/org.apache.derby.server/build.xml
D       java/org.apache.derby.server/org/apache/derby/drda/server.policy
D       java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/util/derby_tests.policy

Removes the source versions of server.policy and derby_tests.policy.

--------------------------------

M       build.xml

Wires policy generation into the compile phase of the Derby build and
adds a target to copy the generated DITA source pages into the docs
directory tree when building release candidates.
{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, derby-3547-01-ab-policyGenerator.diff
>
>
> 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)