Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 79184 invoked from network); 14 Mar 2008 22:06:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Mar 2008 22:06:03 -0000 Received: (qmail 201 invoked by uid 500); 14 Mar 2008 22:06:00 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 164 invoked by uid 500); 14 Mar 2008 22:06:00 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 153 invoked by uid 99); 14 Mar 2008 22:06:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Mar 2008 15:06:00 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Mar 2008 22:05:20 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 3C4CC234C099 for ; Fri, 14 Mar 2008 15:04:24 -0700 (PDT) Message-ID: <848550627.1205532264245.JavaMail.jira@brutus> Date: Fri, 14 Mar 2008 15:04:24 -0700 (PDT) From: "Daniel John Debrunner (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Created: (DERBY-3547) Create a utility that generates a security policy file for Derby's tests MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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.