Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 39446 invoked from network); 26 Feb 2008 14:09:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Feb 2008 14:09:54 -0000 Received: (qmail 96479 invoked by uid 500); 26 Feb 2008 14:09:49 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 96405 invoked by uid 500); 26 Feb 2008 14:09:49 -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 96386 invoked by uid 99); 26 Feb 2008 14:09:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Feb 2008 06:09:49 -0800 X-ASF-Spam-Status: No, hits=-1.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.18.6.21] (HELO gmp-eb-inf-1.sun.com) (192.18.6.21) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Feb 2008 14:09:15 +0000 Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QE9NAj007513 for ; Tue, 26 Feb 2008 14:09:23 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWU00G01M5DYQ00@fe-emea-09.sun.com> (original mail from Vemund.Ostgaard@Sun.COM) for derby-dev@db.apache.org; Tue, 26 Feb 2008 14:09:23 +0000 (GMT) Received: from [129.159.112.187] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWU004CDNBKJLG0@fe-emea-09.sun.com> for derby-dev@db.apache.org; Tue, 26 Feb 2008 14:09:21 +0000 (GMT) Date: Tue, 26 Feb 2008 15:09:20 +0100 From: Vemund Ostgaard Subject: Optional permissions in policy files In-reply-to: <2112881108.1203961491147.JavaMail.jira@brutus> Sender: Vemund.Ostgaard@Sun.COM To: derby-dev@db.apache.org Message-id: <47C41D90.3010201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <2112881108.1203961491147.JavaMail.jira@brutus> User-Agent: Thunderbird 2.0.0.9 (X11/20071119) X-Virus-Checked: Checked by ClamAV on apache.org Based on Dans suggestions to fix an issue with my patch for DERBY-3445, I read up a bit more on policy files and discovered a feature that can be used to make parts of the policy file optional. Since I didn't know about this feature myself, I thought I'd share it with the community, as I think it could be useful if you are trying to figure out how to get a test to run with the security manager. I found the following details on property expansion in policy files here: http://java.sun.com/j2se/1.4.2/docs/guide/security/PolicyFiles.html#PropertyExp --- Also note: If a property can't be expanded in a grant entry, permission entry, or keystore entry, that entry is ignored. For example, if the system property "foo" is not defined and you have: grant codeBase "${foo}" { permission ...; permission ...; }; then all the permissions in this grant entry are ignored. If you have grant { permission Foo "${foo}"; permission Bar; }; then only the "permission Foo..." entry is ignored. And finally, if you have keystore "${foo}"; then the keystore entry is ignored. --- So, if you have some permission you want to be used only in special circumstances, it can be controlled for instance by using a property that is either not set (disabled) or set to an empty string (enabled). Adding this property to some part of the permissions you want to be optional means that these permissions are enabled when the property is set and ignored if the property is not set. Since the property is just set to an empty string, the permission itself is not affected in any way by the property. Vemund Daniel John Debrunner (JIRA) wrote: > [ https://issues.apache.org/jira/browse/DERBY-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572140#action_12572140 ] > > Daniel John Debrunner commented on DERBY-3445: > ---------------------------------------------- > > It's a concern that permissions are always granted to derby.jar, even though they are only needed if performing code coverage with EMMA. > This creates an opportunity where Derby code could unknowingly start to depend on those permissions. > > These permissions are as follows, are they needed for all code in the stack, or just a subset? > > + // These permissions are needed when testing code instrumented with EMMA. > + permission java.util.PropertyPermission "user.dir", "read"; > + permission java.io.FilePermission "${user.dir}${/}coverage.ec", "read"; > + permission java.lang.RuntimePermission "writeFileDescriptor"; > > A work-around may be to add separate sections in the policy file, e.g. if these permissions are only needed for a subset of jars then: > > grant codebase "${emmaActive}/derby.jar" { > permission java.util.PropertyPermission "user.dir", "read"; > permission java.io.FilePermission "${user.dir}${/}coverage.ec", "read"; > permission java.lang.RuntimePermission "writeFileDescriptor"; > }; > > then emmaActive is only set when running code coverage with EMMA. It possible a similar trick could be done if they are needed for all code, > something that resolves to: > grant { > permission java.util.PropertyPermission "user.dir", "read"; > permission java.io.FilePermission "${user.dir}${/}coverage.ec", "read"; > permission java.lang.RuntimePermission "writeFileDescriptor"; > }; > > if and only if some emma property is set