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.
Thanks,
Sean
More information about the security-dev
mailing list