RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path

Sean Mullan sean.mullan at oracle.com
Mon May 4 12:31:51 UTC 2015

On 05/01/2015 12:33 PM, Mandy Chung wrote:
> On 05/01/2015 05:48 AM, Sean Mullan wrote:
>> Please review this change to use the system class loader to locate a
>> policy provider specified with the policy.provider security property.
>> The current implementation tries to load the provider using the
>> extension class loader. This will no longer work when the extension
>> mechanism is removed, which is proposed as part of JEP 220:
>> http://openjdk.java.net/jeps/220
>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.01/
> Looks okay.
> Nit: line 208-209 - this is rather hard to read.   probably worth some
> cleanup/adjustment.

I thought about that, but I think it's best if that code is left as-is 
for now. It is already bumping up against the 80 char limit, so I would 
have to refactor that into another method but there are some subtle 
concurrency issues, so I would prefer not to break up the code just to 
do that. I'll look at this again later as part of another bug.

> CustomPolicy.implies
>    50         if (pd == policyPd) {
>    51             return true;
>    52         }
> This is okay for the test.  Just for my understanding, for real world
> custom policy, should it check the code source in case the sensitive
> operation triggering a permission check involving other classes?

Permissions are granted per ProtectionDomain (PD) so this is sufficient. 
However, typically the policy provider would be in a separate PD from 
other code (for example, by packaging it in a separate JAR file), but 
this is sufficient for testing purposes. If you remove the lines above 
from the test, you will get a StackOverflowError.


More information about the security-dev mailing list