db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-3547) Create a utility that generates a security policy file for Derby's tests
Date Sun, 09 Dec 2018 23:22:00 GMT

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

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

Attaching derby-3547-05-aa-fixCanonicalization.diff. The last patch actually did nothing--it
deleted a non-existent permission rather than adding the new permission. Let's try this again.

I will run tests with the classpath on my mac.

Touches the following file:

{noformat}
M       java/org.apache.derby.engine/org/apache/derby/security/securityPolicies.xml

Grant the engine jar another permission so that file names can be
canonicalized on Windows.
{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
>            Assignee: Rick Hillegas
>            Priority: Minor
>             Fix For: 10.15.0.0
>
>         Attachments: SecurityPolicyVTI.java, derby-3547-01-ab-policyGenerator.diff, derby-3547-02-aa-remainingTestPolicies.diff,
derby-3547-03-aa-removeTemplatePolicy.diff, derby-3547-04-aa-canonicalizeFileNamesOnWindows.diff,
derby-3547-05-aa-fixCanonicalization.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)

Mime
View raw message